tmutil localsnapshot 报错通常源于路径错误、filevault 状态不同步或 auth.db 损坏；需依次检查挂载点路径、解锁 apfs 卷、修复 /var/db/auth.db，最后才考虑磁盘急救。
tmutil localsnapshot 命令报错：No such file or directory
这通常不是快照功能本身坏了，而是系统找不到目标宗卷路径——尤其在 macOS Sequoia 启用新式分离宗卷（Macintosh HD + Macintosh HD - Data）后，tmutil localsnapshot 默认只认系统宗卷（即只读的 Macintosh HD），但如果你手误指了 Data 卷或拼错了路径，就会直接报这个错误。
- 先确认当前启动宗卷名：
diskutil apfs list | grep "Mount Point"，找到挂载点为/的那个宗卷名（大概率是Macintosh HD，不是Macintosh HD - Data） - 执行时必须用完整、带空格转义的路径：
tmutil localsnapshot /Volumes/Macintosh\ HD - 别对
Data宗卷手动建快照——APFS 会自动同步元数据，强行操作可能触发EPERM或静默失败 - 如果路径没错还报错，检查是否在恢复模式下运行（
tmutil在恢复环境不可用）
快照创建卡住或返回 Operation not permitted
这是 FileVault 加密与快照权限链断裂的典型表现。系统宗卷虽已解锁，但内核级快照驱动无法获取 APFS 容器的写时复制（CoW）授权，尤其在刚升级完大版本、重启未完成密钥链同步时高发。
- 先验证加密状态：
diskutil apfs list | grep -A5 "Macintosh HD"，确认两宗卷的Encryption字段是否都显示Unlocked - 若
Data卷显示Locked，需手动解锁：diskutil apfs unlockVolume /dev/diskXsY -passphrase [你的登录密码]（diskXsY从上一步输出中找） - 解锁成功后再跑
tmutil localsnapshot，否则即使命令返回 success，快照实际也未持久化 - 注意：此问题在启用 FileVault + 使用 iCloud 钥匙串同步密码的机器上更常见，本地密码缓存未刷新会导致 -passphrase 认证失败
快照创建成功但 time machine 恢复时提示 “无法验证备份”
这不是快照没建好，而是 auth.db 认证数据库损坏导致签名链中断。该文件位于系统宗卷的 /var/db/auth.db，负责校验快照来源可信性。大版本升级后首次回滚极易触发，现象是恢复界面反复弹窗或黑屏退出。
- 进恢复模式（Apple Silicon：长按电源键→选“选项”；Intel：Cmd+R），打开终端
- 定位文件：
ls /Volumes/*/var/db/auth.db，正常应看到类似/Volumes/Macintosh HD/var/db/auth.db - 删掉它：
rm /Volumes/Macintosh\ HD/var/db/auth.db（路径务必和上一步输出一致，空格要转义） - 重启后立刻再试时间机器恢复——系统会在首次挂载时重建 auth.db，无需重装或抹盘
- 别跳过这步去“急救磁盘”，auth.db 损坏不会触发磁盘工具报错，但会让所有快照失效
本地快照空间占满导致创建失败：No space left on device
APFS 快照本身不占额外空间，但系统会为本地快照预留一个隐藏的“快照存储池”，默认上限约 20% 宗卷容量。一旦被旧快照塞满（比如长期未重启、Time Machine 备份频繁），tmutil localsnapshot 就会因无可用元数据槽位而失败。
- 查当前快照列表：
tmutil listlocalsnapshots /，观察数量是否超过 10–15 个 - 清理过期快照：
sudo tmutil thinlocalsnapshots / --keep-alive 1（强制保留最新一个，其余全清） - 若仍报错，说明宗卷底层碎片严重，需进恢复模式用磁盘工具逐级急救：
Macintosh HD - Data→Macintosh HD→ 容器 → 物理 SSD - 注意：
thinlocalsnapshots不释放已分配但未使用的空间，必须配合磁盘急救才能真正腾出连续块
快照失败最常卡在「路径写错」「FileVault 状态不同步」「auth.db 损坏」这三个点，它们都不需要重装系统，但顺序不能乱：先校验路径和加密状态，再处理 auth.db，最后才动磁盘急救——错一步，后面全白忙。
