关于更换操作系统后 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` 被别名/函数占用，会直接静默失败。统一日志工具请写全路径：
```bash
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 端
用内嵌密码手动挂载：
```bash
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`：
```bash
/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 读的文件：
```bash
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：“这服务器我不认识，不试。” ✗
## 修复
### 第一步：把新服务器加进已知名单（键名必须全小写！）
```bash
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 共享 → 输入账号密码。
然后触发备份验证：
```bash
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”。
三条一条都没做，于是唯一的解法落在用户手动编辑内部状态文件上。
## 诊断工具箱（收藏备用）
```bash
# 看 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 服务器能从设置里配成功，换服务器身份后必踩此坑。
---
原文链接：[点击查看](https://www.v2ex.com/t/1228391)
实际上，飞牛社区某个不起眼的楼中楼回复给出了下面 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` 被别名/函数占用，会直接静默失败。统一日志工具请写全路径：
```bash
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 端
用内嵌密码手动挂载：
```bash
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`：
```bash
/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 读的文件：
```bash
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：“这服务器我不认识，不试。” ✗
## 修复
### 第一步：把新服务器加进已知名单（键名必须全小写！）
```bash
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 共享 → 输入账号密码。
然后触发备份验证：
```bash
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”。
三条一条都没做，于是唯一的解法落在用户手动编辑内部状态文件上。
## 诊断工具箱（收藏备用）
```bash
# 看 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 服务器能从设置里配成功，换服务器身份后必踩此坑。
---
原文链接：[点击查看](https://www.v2ex.com/t/1228391)
· 0 个赞