本篇文章更新時間：2026/02/02
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知。
一介資男的 LINE 社群開站囉！歡迎入群聊聊～
如果本站內容對你有幫助，歡迎使用 BFX Pay 加密貨幣 或 新台幣 贊助支持。
內容目錄
Time Machine 又壞了：從 macOS Tahoe 出包後，我重新檢查了所有備份設定
編輯前言：這篇筆記源自作者在 macOS Tahoe 上遇到的 Time Machine 靜默失效案例，讓我再次意識到備份系統不能只靠單一供應商。原文出自 TIL: Apple Broke Time Machine Again On Tahoe。
核心觀點 (Key Takeaways)
- Time Machine 在 macOS Tahoe 上可能因 SMB 預設值變更而「悄悄失效」，完全沒有警示。
- 解法包含：修改本機的
nsmb.conf、調整 Synology SMB 設定，或乾脆改用 Docker-based Time Machine server。 - 依賴 Apple 的 SMB 行為太不可靠，作者傾向轉向更可控的自架方案。
深入解析
這篇原文的情境非常生活化：作者想從 Time Machine 撈回 Obsidian vault，結果發現備份早就停擺兩個月，而且沒有任何警告。這種「悄悄失效」是最可怕的備份災難——因為你永遠是在需要備份的那一刻才發現自己沒有備份。
作者追查後發現問題源自 macOS Tahoe 對 SMB 的預設更改。「signing_required」被強制變得更嚴格，而像 Synology 這種預設較寬鬆的 SMB 實作就無法正常對接。
作者引用的解法中提到：「macOS Tahoe changed the default from signing_required=no to stricter control」。
1. 透過 nsmb.conf 強制調整 SMB 行為
他在 Mac 上建立並編輯 /etc/nsmb.conf，加入：
[default]
signing_required=yes
streams=yes
soft=yes
dir_cache_max_cnt=0
protocol_vers_map=6
mc_prefer_wired=yes
這種做法雖然有效，但屬於「與 Apple 對抗」的 workaround——下次系統更新可能再次失效。
2. 調整 Synology 的 SMB 設定
作者也檢查 NAS 端設定，確保：
- SMB3 最大協定
- 啟用 Opportunistic Locking / SMB2 Lease / Durable Handles
- Server signing 設為 No 或 Auto
這些設定大致與 Synology 社群常見建議一致，但不同 DSM 版本 UI 會有差異。
3. 乾脆用 Docker 架自己的 Time Machine server
因為對 Apple 反覆踩坑已心生倦意，作者另外測試了 mbentley/timemachine Docker image，部署於 Proxmox + ZFS 之上。這讓他完全掌控 SMB 行為，也避免依賴 Synology 封閉的協定調校。
他提供了 Docker Compose 範例，算是非常務實的解法：不再等 Apple 修，而是自己打造穩定的備份環境。
筆者心得與啟發
讀完後，我最大的感受是：備份系統最怕「靜默失效」。Apple 過去幾年在 Time Machine、iCloud Restore、甚至 iOS 設備還原流程中，都出現了讓人意外的可靠性問題。原文最後提到的 iOS Restore bug，我自己也遇過多次，完全能理解那種無力感。
這篇文章給我的三個啟發：
- 不要盲信內建備份系統。無論 Apple 多強調 Time Machine「簡單」、「安心」，現實是，你永遠需要第二方案。
- 跨平台協定（SMB）牽涉多方，任何一邊更新都可能出問題。Synology、Docker、自架 SMB，各有不同的穩定度，但至少自架能掌握變因。
- 定期驗證備份比定期備份更重要。「可以成功還原」才是備份的真正目的。
如果你也依賴 Synology + Time Machine，近期真的該檢查一下自己的備份最後時間，尤其是在升級到 macOS Tahoe 之後。
備份這件事沒什麼浪漫，卻是所有創作者與工作者最重要的基礎工程。希望 Apple 能把注意力放回 OS 體驗本身，而不是那些表面的亮面玻璃噱頭。