关于更换操作系统后 TimeMachine 无法备份的解法

最近给 NAS 重装了系统，把绿联刷飞牛 OS ，macOS Time Machine 突然无法备份，提示”备份失败”。密码绝对正确、手动挂载完全正常，但 Time Machine 就是连不上。

实际上，飞牛社区某个不起眼的楼中楼回复给出了下面 AI 耗时 2 个小时自行探索修复的结论，只不过写得不太清楚。

症状

• Time Machine 永远备份失败，系统通知只有一句”备份失败”，提示的是这个：

• tmutil destinationinfo 正常，defaults read /Library/Preferences/com.apple.TimeMachine 里 RESULT = 29。

• 在 Finder / 终端里用 mount_smbfs //user:password@nas/Share 挂载备份共享完全正常——网络、账号、密码、共享配置、NAS 端 Samba 全部无辜。

• NAS 的 Samba 日志里看不到任何来自 Mac 的认证尝试——失败发生在 Mac 本地，认证包根本没发出去。

环境

• macOS 15.7 (Sequoia)，备份目标为 SMB 共享（本文案例：绿联硬件刷飞牛 OS 后的 Samba ，开启了 fruit:time machine）。
• 路由器做了 IP-MAC 绑定，NAS 重装系统后 IP 不变。

排查过程（可直接复用的诊断路径）

1. 拿到真正的报错

注意：很多人的 shell 里 log 被别名/函数占用，会直接静默失败。统一日志工具请写全路径：

tmutil startbackup   # 手动触发一次备份
/usr/bin/log show --last 5m --info --debug --style compact \
  --predicate 'process == "backupd"' | grep -iE 'error|fail|mount'

典型输出：

[Mounting] Attempting to mount 'smb://app@pdnas._smb._tcp.local./TimeMachine'
[Mounting] NAConnectToServerSync failed with error: 80 (Authentication error)
[BackupDispatching] Backup failed: BACKUP_FAILED_AUTHENTICATION_ERROR (29)

错误 29 只是外层包装，真身是 NetAuth 的 EAUTH (80)。

2. 排除 NAS 端

用内嵌密码手动挂载：

mkdir /tmp/tm && mount_smbfs '//user:password@192.168.x.x/TimeMachine' /tmp/tm

能挂上 = 网络/SMB/凭据/共享全通。再去 NAS 上看 Samba 日志（/var/log/samba/log.*），失败时间点一条记录都没有 → 客户端本地失败。

3. 盯住真正的认证代理 NetAuthSysAgent

Time Machine 以 root 运行，认证走 NetAuthSysAgent：

/usr/bin/log show --last 2m --info --debug --style compact \
  --predicate 'process == "NetAuthSysAgent"'

关键日志：

[Keychain] isKnownServer 0
[MechTypes] CredentialsStage set to 5
[MechTypes] There are no user credentials to add to the MechType session
[NetFS] OpenSession failed 80

isKnownServer 0 —— NetAuth 认为这台服务器”不认识”，直接跳到第 5 阶段，连钥匙串都不查就放弃了。

4. 找到”已知服务器”名单

用 fs_usage 跟踪 agent 读的文件：

sudo fs_usage -w -f filesys NetAuthSysAgent
# 另一个终端触发 tmutil startbackup

会发现它读取：

/private/var/root/Library/Group Containers/group.com.apple.NetworkAuthorization.ServerMarkers/serverMarkers.plist

打开一看（需要 sudo ）：

"ugreen-cd13.local" => 1
"ugreen-cd13-2.local" => 1
_migrationVersion => 2

只有旧系统的主机名，没有重装后的新主机名，也没有 IP 。

根因

macOS 的 NetAuth 框架维护一份”已知服务器”标记（ ServerMarkers ）。对不在名单里的服务器，NetAuthSysAgent 在无交互权限的系统上下文中（ Time Machine 正是如此）直接判定 isKnownServer = 0，跳过钥匙串查询、不发出任何认证包，向上层返回 EAUTH 。

NAS 重装系统后，尽管 IP 没变，但 Bonjour 主机名、Samba 服务标识全变了——在 Mac 眼里这是一台全新的、从未信任过的服务器。而 GUI （系统设置/Finder ）添加凭据的流程不知为何没有把新主机名写进标记（这在重装 NAS 的场景下似乎不会自动发生），于是形成死锁：

• 钥匙串里有正确密码 ✓
• 服务器一切正常 ✓
• NetAuth：”这服务器我不认识，不试。” ✗

修复

第一步：把新服务器加进已知名单（键名必须全小写！）

PL="/private/var/root/Library/Group Containers/group.com.apple.NetworkAuthorization.ServerMarkers/serverMarkers.plist"
sudo cp "$PL" "$PL.bak"   # 先备份

sudo /usr/libexec/PlistBuddy -c "Add :192.168.x.x integer 1" "$PL"
sudo /usr/libexec/PlistBuddy -c "Add :your-nas._smb._tcp.local. integer 1" "$PL"
sudo /usr/libexec/PlistBuddy -c "Add :your-nas.local integer 1" "$PL"

三个坑：

1. 键名全小写——主机名比较是小写的，PDNAS.local 写了等于没写（对照名单里原有的 ugreen 条目，全是小写）。
2. 用 PlistBuddy 而不是 plutil -insert——plutil 把键名里的 . 当作嵌套路径分隔符，含点的主机名会静默失败； PlistBuddy 的路径分隔符是 :，点号是安全的。
3. 三个名字（ IP 、Bonjour 服务名、mDNS 主机名）都加上，因为 Time Machine 目的地 URL 可能用其中任意一种。可用 tmutil destinationinfo 看你的 URL 用的是哪种。

第二步：重新添加备份目的地

系统设置 → 通用 → 时间机器 → 选择备份磁盘 → 选中 NAS 上的 TimeMachine 共享 → 输入账号密码。

然后触发备份验证：

tmutil startbackup && sleep 15 && tmutil status

看到 Running = 1、BackupPhase = Copying 即修复完成。此时再回头抓 NetAuthSysAgent 日志，会看到流程变成：

[Keychain] isKnownServer 1
[MechTypes] Next CredentialsStage set to 4
[MechTypes] MechTypes were acquired for the MechType session using credentials

顺手清理（可选）

• 旧 NAS 的标记（本例中的 ugreen-cd13*）：留着无害，想删可以用 PlistBuddy -c "Delete :ugreen-cd13.local" "$PL"。
• 钥匙串里指向旧 NAS 身份的残留条目：钥匙串访问.app 搜 NAS 名字/IP 删掉即可。
• 如果之前用命令行折腾过 tmutil setdestination -ap，注意它写的是旧式 /Library/Keychains/System.keychain，而 macOS 15 的 NetAuthSysAgent 查的是新式 system-keychain-2.db——命令行加的条目它可能根本看不到，以 GUI 添加的为准。

深层定性：这是 macOS 的锅，而且能从机制反推出一个惊人结论

三层状态，各自为政

macOS 实际维护三套互相同步不良的认证状态：

状态	位置	谁写	谁读
“已知服务器”信任标记	serverMarkers.plist	仅特定交互式流程（首次配置等）	NetAuthSysAgent
旧式凭据	/Library/Keychains/System.keychain	TM 设置 UI 、tmutil CLI	部分遗留 API
新式凭据库	system-keychain-2.db	系统级 SecItem 流程	NetAuthSysAgent 的 SecItem 查询

在系统设置里输入密码时，GUI 真实连接了 NAS 并验证成功（ NAS 日志有访问记录）、也写入了钥匙串——但没有写信任标记。后端 daemon 只认标记。UI 的”成功”和后端的”信任”是两套语义，这是字面意义上的脱钩。而整个失败链条最终坍缩成一句”备份失败 / 错误 29”，用户能做的所有常规操作（重输密码、删了重加、换 IP 换域名）都够不到真正出问题的那层状态。

时间线复盘：两个诱因叠加

• serverMarkers.plist 的文件修改时间停留在首次配置旧 NAS 的那天，此后再未被任何流程更新；
• 刷入新 NAS 系统（飞牛 OS ）后，主机名/Samba 身份变更，但 IP 因路由绑定没变——新身份从未进入信任名单（埋雷）；
• 备份在新系统上正常跑了一段时间，直到一次 macOS 更新（机器重启时间吻合）后突然全挂——很可能是该更新引入了 marker 迁移（_migrationVersion = 2）或收紧了 isKnownServer 校验（引爆）。

反推结论：”第一台服务器定律”

把上面的事实拼起来，可以得出一个可检验的强推论：

在一台 macOS 设备上，只有它这辈子连接的第一台 Time Machine 服务器，能够从系统设置里顺利完成备份。

推理过程：

1. 首次配置 TM 时，某个 onboarding 流程在验证凭据成功后会写入 serverMarkers.plist——所以第一台服务器永远顺利；
2. 此后这个文件再无任何面向用户的流程会更新它（实测：设置 UI 里重输密码、删除磁盘再添加、命令行 tmutil setdestination，全部不会写标记）；
3. 于是第二台服务器（换 NAS 、NAS 重刷系统、改主机名都会让 Mac 认为是”新服务器”）永远卡在 isKnownServer = 0——钥匙串里密码再正确也不会被使用；
4. 唯一出路就是手动编辑那个没有文档、不在任何官方排障流程里的 plist 。

限定条件：本结论基于 macOS 15.7 上一次可完整复现的案例 + 完全自洽的机制解释，样本量为 1 。如果你手上有”换 NAS 后第二台 TM 服务器直接从设置里配成功”的反例，欢迎打脸——那至少说明 Apple 在新版本里修了。

实操推论：标记是按主机名字符串匹配的。所以换新 NAS / 重刷系统时，把新主机名（ Bonjour 名）设置成和旧的完全一致，老标记直接命中，大概率可以无感迁移、免疫此坑。

Apple 应该怎么做（三条任选其一即可治本）

1. TM 设置 UI 验证凭据成功时同步写入 serverMarkers ；
2. NetAuthSysAgent 把”钥匙串中存在该服务器的有效凭据”视为 known 的兜底条件；
3. 至少把 “untrusted/unknown server” 作为独立错误暴露给用户，而不是笼统的”备份失败 / 错误 29”。

三条一条都没做，于是唯一的解法落在用户手动编辑内部状态文件上。

诊断工具箱（收藏备用）

# 看 TM 配置和最近一次结果码
tmutil destinationinfo
defaults read /Library/Preferences/com.apple.TimeMachine

# 抓 backupd 报错（/usr/bin/log 全路径，避开 shell 别名坑）
/usr/bin/log show --last 10m --info --predicate 'process == "backupd"'

# 抓 NetAuth 认证流程
/usr/bin/log show --last 2m --info --debug --predicate 'process == "NetAuthSysAgent"'

# 跟踪 NetAuthSysAgent 读了哪些状态文件
sudo fs_usage -w -f filesys NetAuthSysAgent

# 验证"密码本身没问题"（内嵌密码挂载）
mkdir /tmp/t && mount_smbfs '//user:pass@nas-ip/Share' /tmp/t

注意：mount_smbfs 不带密码在非交互终端下不会查钥匙串，会以空凭据被服务器拒绝（ exit 77 ），不要用它来判断钥匙串条目是否有效——这是排查时最容易踩的假线索。

总结

表象	真相
“认证失败 (EAUTH 80)”	NetAuth 根本没发起认证
“密码不对？”	密码一直是对的
“NAS 坏了？”	NAS 日志里连尝试记录都没有
Time Machine 错误 29	服务器不在 NetAuth 的”已知名单”里

一句话：NAS 重装/更换后，把新主机名（小写）和 IP 加进 serverMarkers.plist，再走一遍系统设置添加备份磁盘，即可恢复。 更深层次上，这是 macOS 设置 UI 与后端认证体系脱钩的 bug——一台 Mac 这辈子只有第一台 TM 服务器能从设置里配成功，换服务器身份后必踩此坑。