macOS Tahoe 26.4 导致 Time Machine SMB 备份中断：nsmb.conf 修复方案（等待 26.5）

如果你在 2026 年 3 月底安装了 macOS Tahoe 26.4，并且发现 Time Machine 向 Synology、QNAP、UGREEN、TrueNAS 或 Asustor NAS 的备份突然停止工作，请放心，遇到这个问题的不止你一个人。Apple 在 26.4 版本中悄然收紧了操作系统的 SMB 签名默认设置，这一变化导致 Time Machine 与市面上几乎所有第三方网络附加存储设备的连接均告中断。4 月 9 日发布的 26.4.1 补丁修复了若干其他问题，但并未解决 Time Machine SMB 回归问题。

好消息是，有一个已知的临时解决方案可以今晚就应用，而且 Apple 已经在 macOS 26.5 beta 4（版本号 25F5068a，于 2026 年 4 月 27 日发布）中修正了这一行为。坏消息是，26.5 正式版预计要到 5 月下旬才会发布，就在 2026 年 6 月 8 日 WWDC 之前。这意味着大多数 NAS 用户在手动处理之前，将面临数周的备份中断。

本指南将详细说明底层发生了什么变化，逐步介绍 /etc/nsmb.conf 修复方案及需要粘贴的精确内容，汇总各主要 NAS 厂商的现状，评估在家庭或办公室局域网上放宽 SMB 签名的安全权衡，并概述在等待期间可以运行的更安全的临时备份策略。读完本文后，你将恢复正常备份，并清楚地了解你做出了哪些让步以及如何在 macOS 26.5 发布后回滚此更改。

核心要点

• 问题所在： macOS Tahoe 26.4 将 Time Machine 连接的 SMB 签名设为默认必需。大多数第三方 NAS 设备不以 macOS 26.4 所接受的方式通告 SMB 签名，因此 SMB 会话在 Time Machine 挂载稀疏捆绑包之前即被拒绝。
• 受影响的厂商： Synology DSM 7.2 及更早版本、QNAP QTS 5.1.x、UGREEN UGOS 1.x、Asustor ADM 4.x、TrueNAS SCALE 24.x（开箱即用），以及许多其他第三方 SMB 目标。macOS 到 macOS 的 SMB Time Machine 仍可正常工作。
• 症状：「Time Machine 无法完成备份」、「操作不被允许」、循环出现的凭据提示、能挂载但报告无法读取的稀疏捆绑包，以及在几秒内中止的完整重新备份尝试。
• 修复方法： 创建 /etc/nsmb.conf，写入 signing_required=no 和 protocol_vers_map=7，等待 NAS 固件更新或 macOS 26.5 发布。
• 风险： 禁用 SMB 签名会将 SMB 会话暴露于本地网络中的中间人篡改攻击。在受信任的家庭局域网上可以接受，在共享办公室 Wi-Fi 或共享办公网络上则不太适合。
• 修复时间线： macOS 26.5 beta 4 据报已解决该回归问题。26.5 正式版预计在 2026 年 5 月下旬的 WWDC 之前发布。

问题的起因与时间

Apple 于 2026 年 3 月底发布了 macOS Tahoe 26.4，这是 Tahoe 周期的第二个功能更新。发布说明重点介绍了 Apple Intelligence 的改进、日历应用的更新以及一长串安全修复。在那份安全列表中，悄悄埋着一项对 macOS 内置 SMB 客户端的更改，加固了内核协商 SMB 会话的方式。Apple 没有在主要发布说明中单独指出这一点，但对于任何将 Time Machine 目标设为第三方 NAS 的用户来说，影响是立竿见影的。

26.4 推出后的 48 小时内，Apple 社区帖子 256221835 开始汇集 Synology 和 QNAP 用户的投诉，描述相同的症状。Hacker News 条目 46848699 上的平行讨论积累了数百条来自运行各类消费级和专业级 NAS 用户的回复。规律显而易见：多年来每晚正常运行的备份，在 26.4 更新后的第一次尝试就突然拒绝初始化。

Apple 于 2026 年 4 月 9 日发布了 26.4.1，修复了若干不相关的回归问题，包括 Wi-Fi 漫游问题和邮件渲染错误。Time Machine SMB 问题不在 26.4.1 的修复说明中，测试也证实该回归问题在这个小版本中依然存在。原本希望 26.4.1 能悄然恢复旧行为的用户感到失望，Apple 社区帖子的基调也从「只有我遇到这个问题吗」转变为「Apple 需要正式承认这个问题」。

要全面了解 26.4 发布周期及其他值得关注的回归问题，请参阅我们的 macOS Tahoe 26.4 和 26.4.1 完整更新指南。

症状一览

Time Machine SMB 回归问题根据 NAS 厂商、固件版本以及升级前 Time Machine 的配置方式，会以几种不同的形式表现出来。以下按照用户报告中出现的大致顺序列出最常见的症状。

Time Machine 在 26.4 之后第一次预定备份时初始化失败。 Time Machine 菜单栏图标旋转几秒后显示「Time Machine 无法完成备份到 [共享名称]」。在系统设置中打开 Time Machine 显示目标仍在配置中，但下一次备份尝试同样失败。

循环出现的凭据提示。 macOS 要求输入 SMB 共享的用户名和密码，接受凭据后立即再次询问。将凭据保存到钥匙串也无济于事，因为 SMB 会话本身在比身份验证更底层的地方被拒绝了。

「操作不被允许」或 POSIX 错误 1。 这是底层日志中最常见的错误字符串。出现这个错误是因为 NAS 上的稀疏捆绑包在技术上是可达的，但 macOS 拒绝挂载它，因为 SMB 会话被降级或在没有 macOS 26.4 现在坚持的签名属性的情况下协商完成。

稀疏捆绑包可以挂载但报告无法读取。 一小部分用户看到备份卷在 Finder 中挂载，但 Time Machine 报告该卷无法使用。这通常发生在共享协商了未签名的 SMB1 或 SMB2 会话作为回退，而 macOS 拒绝向其写入的情况下。

完整重新备份尝试在几秒内中止。 一些用户尝试通过删除目标并重新添加来「修复」问题，希望全新备份能够正常工作。结果是重新备份协商了同样有问题的 SMB 会话并几乎立即中止，有时在 NAS 上留下一个空的占位稀疏捆绑包。

控制台日志条目引用 smbfs、signature mismatch 或 STATUS_ACCESS_DENIED。 在故障发生时打开 Console.app 并过滤 smb，会显示关于签名协商的内核消息。这是签名更改的明确证据。

如果你同时遇到以上几种症状，几乎可以确定是遇到了 26.4 SMB 签名回归问题，而不是 NAS 硬件故障、网络问题或稀疏捆绑包损坏。关于不涉及 SMB 层的更广泛 Time Machine 诊断，请参阅 完整的 Time Machine 故障排除指南。

问题根源：Apple 的 SMB 签名变更详解

要理解为什么修复方案有效，有必要了解 SMB 签名究竟是什么，以及 Apple 为何决定在 26.4 中更改默认设置。

SMB 签名是服务器消息块协议的一项功能，macOS 在连接 Windows 共享、Samba 服务器或 NAS 时使用该协议进行文件共享。当启用 SMB 签名时，客户端发送到服务器的每个数据包都包含一个从会话密钥派生的加密签名。服务器验证每个数据包上的签名，并以同样的方式对其响应进行签名。结果是，同一网络上的攻击者无法在传输过程中篡改文件内容而不导致签名失败和连接中断。

SMB 签名自 SMB1 就已存在，在许多 Windows 工作负载中，SMB3 默认要求签名。客户端和服务器之间的协议协商决定签名是「未使用」、「启用但可选」还是「必需」。在 macOS 26.4 之前，macOS SMB 客户端乐于在服务器不要求签名的情况下协商未签名会话，这是大多数消费级 NAS 设备出于性能原因所采用的路径。

在 26.4 中，Apple 更改了 macOS 默认设置，使客户端现在要求会话签名，除非另行明确说明。当客户端连接到通告签名为可用但非必需的 NAS 时，macOS 现在拒绝回退到未签名模式。会话协商以错误结束，SMB 挂载失败，Time Machine 没有可写入的目标。

Apple 为什么这样做？这一变更与业界多年来加固 SMB 的努力一致。微软在 Windows 11 24H2 中将签名设为默认必需，SMB 社区一直在迁移到强制签名的 SMB 3.1.1，而 Apple 的企业客户也一直在寻求同样的功能。勒索软件威胁模型包括攻击者从被攻陷的端点转移到文件共享并在传输过程中篡改备份文件，而 SMB 签名是最有效的缓解措施之一。

问题在于，NAS 厂商没有获得明确的弃用过渡期。Synology、QNAP 和 UGREEN 设备默认启用签名但不要求签名，以便较旧的 Windows 客户端和嵌入式设备仍然可以连接。macOS 26.4 实际上要求这些厂商翻转自己的默认设置，但这在大多数平台上不是一次固件更新就能解决的问题，因为这会破坏同一网络上的其他客户端。

要全面了解 macOS Tahoe 上的 SMB 栈以及 SMB 连接失败的许多其他方式，请参阅 完整的 SMB 和 NAS 故障排除指南。

nsmb.conf 修复步骤

最简洁的解决方案是告诉 macOS，对于你信任的连接，你愿意接受没有签名的 SMB 会话。macOS 在每次 SMB 会话建立时都会读取 /etc/nsmb.conf 配置文件，你可以在那里设置一个全局标志，恢复 26.4 之前的行为。

开始之前有两个警告。第一，此更改适用于你的 Mac 建立的每个 SMB 连接，而不仅仅是 Time Machine，因此请确保你对本文后面描述的安全权衡感到满意。第二，编辑 /etc/nsmb.conf 需要管理员权限，应该谨慎操作，因为格式错误的文件会导致 SMB 连接以不同且不那么明显的方式失败。

快速修复：一行命令

如果你只想在睡前让备份正常工作，并且熟悉终端，以下命令可以一次性创建包含必要设置的文件。从「应用程序」>「实用工具」打开「终端」，然后原样粘贴该命令。系统将提示你输入管理员密码。

sudo tee /etc/nsmb.conf >/dev/null <<'EOF'
[default]
signing_required=no
protocol_vers_map=7
EOF

signing_required=no 这行告诉 macOS SMB 客户端签名是可选的而非必需的。protocol_vers_map=7 这行是一个位掩码，允许协商 SMB 1、SMB 2 和 SMB 3，这是旧版默认值。在大多数现代 NAS 设备上，实际上只会使用 SMB 2 和 SMB 3，但在映射中包含 SMB 1 可防止协商完全没有找到协议的边缘情况。

运行命令后，从 Finder 中推出当前已挂载的所有 SMB 共享，等待十秒，然后通过名称重新连接到共享。下一次 Time Machine 备份尝试应该可以正常进行。

持久修复：手动编辑 /etc/nsmb.conf

如果你想在提交之前查看文件，或者以后想添加每台服务器的覆盖配置，可以用带 sudo 的文本编辑器创建或编辑该文件。使用你喜欢的任何编辑器；nano 随 macOS 提供，对于偶尔使用终端的用户来说是最友好的选项。

sudo nano /etc/nsmb.conf

粘贴以下内容，按 Control-O 然后回车保存，按 Control-X 退出。

[default]
signing_required=no
protocol_vers_map=7

# Optional: target a specific NAS by hostname.
# Replace synology.local with your NAS hostname.
[synology.local]
signing_required=no

[default] 部分适用于每个 SMB 连接。可选的第二部分使用你的 NAS 主机名作为节名，覆盖单个主机名的默认设置，如果你只想放宽 NAS 的签名要求，同时对企业文件服务器的连接保持严格设置，这非常有用。

对于需要更精细控制的用户，另一种方法是使用 /Library/Preferences/com.apple.NetworkAuthorization.plist 中的属性列表或鲜为人知的 serverMarkers.plist 机制，将特定服务器标记为「旧版」并绕过新的签名逻辑。plist 方法侵入性更强，文档也不如 nsmb.conf 齐全，因此我们只在 nsmb.conf 对你特定的 NAS 固件组合无效时才推荐使用。

验证修复是否生效

保存文件后，你的 Mac 协商的下一个 SMB 会话将遵循新的默认设置。要验证文件是否被正确读取，从终端运行以下命令。

cat /etc/nsmb.conf

你应该看到你写入的确切内容。如果文件为空或显示不同的 [default] 块，则可能有来自之前修复尝试的旧版本。

要实时观察 SMB 协商过程，打开 Console.app，在搜索字段中输入 smb，然后触发 Time Machine 备份或手动挂载共享。你应该看到成功的会话建立，随后是到共享名称的树连接。应用修复之前的失败会在同一流中记录签名或签名错误，修复后这些错误的消失是修复生效的明确指标。

如果你想确认协商的 SMB 协议版本，打开活动监视器，切换到网络选项卡，你会看到 smbd 连接。你也可以从终端运行 smbutil statshares -a，它会列出每个活动的 SMB 共享及其协商的 SMB 方言。读取到 SMB_VERSION SMB_3_0_2 或更高版本以及 SIGNING_SUPPORTED TRUE 意味着签名仍在被机会性地使用，即使不再是必需的，这是最好的结果。

一旦 Time Machine 成功完成第一次备份，你可以保留该配置，直到 macOS 26.5 发布。要回滚，删除 /etc/nsmb.conf 或将 signing_required=no 改为 signing_required=yes，然后重新连接共享。

各 NAS 厂商状态

回归问题的严重程度及厂商侧修复的可用性因 NAS 平台而异。以下是截至 2026 年 5 月初的情况。

Synology DSM。 Synology 于 2026 年 4 月中旬发布了 DSM 7.2.2 update 4，其中包含一个在服务器端要求 SMB 签名的配置开关。在「控制面板」>「文件服务」>「SMB」>「高级设置」中启用该开关，可以在 Mac 上不使用 nsmb.conf 修复方案的情况下恢复 Time Machine 功能。较旧的 DSM 7.1 和 DSM 6.2 系统没有此开关，需要客户端侧修复方案。Synology 已在社区帖子中确认，DSM 7.2.3 将使签名必需成为新安装的默认设置。

QNAP QTS。 QTS 5.1.7 在「控制面板」>「网络和文件服务」>「Win/Mac/NFS/WebDAV」>「SMB 高级选项」下添加了类似的设置。该开关标记为「强制 SMB 签名」。启用它对大多数用户有效，但一部分用户报告说，QTS SMB 栈只有在共享本身被重新创建后才能正确协商。QTS 5.2.0 beta 正在测试中，预计将使签名必需成为默认设置。

UGREEN UGOS。 UGREEN 的响应较慢。截至 2026 年 4 月下旬，UGOS 1.4 添加了一个启用要求签名的 SMB 3.1.1 的 beta 固件，但该固件尚未正式发布，需要通过 beta 渠道选择加入。使用稳定版 UGOS 固件的 UGREEN 用户应计划在未来几周内使用 nsmb.conf 修复方案。

TrueNAS。 TrueNAS SCALE 24.10 搭载 Samba 4.20，开箱即支持要求签名。可以通过编辑 SMB 服务辅助参数并添加 server signing = mandatory 来启用该设置。应用更改后重启 SMB 服务。使用较旧 Samba 版本的 TrueNAS CORE 用户可能需要先更新才能获得服务器侧修复。

Asustor ADM。 ADM 4.3.1 在「服务」>「Win/Mac/NFS」中添加了「强制 SMB 签名」开关，但在配备低端 CPU 的较旧 Asustor 设备上启用该功能，据报会因每包签名开销导致 SMB 吞吐量下降 20 至 30%。这种权衡可能会促使 Asustor 用户转而在 Mac 上使用客户端侧修复方案。

其他厂商。 Drobo、WD My Cloud Pro 及若干规模较小的厂商尚未发布固件更新。nsmb.conf 修复方案适用于所有情况。如果你的 NAS 运行现代版 Samba（4.18 或更新），在设备的 smb.conf 中启用 server signing = mandatory 也应该有效，但只有在你熟悉维护自己的 Samba 配置的情况下才尝试这种方法。

对于考虑采用不依赖单一易受攻击点的长期备份策略的用户，请参阅 2026 年最佳 Mac 备份策略，了解如何将 Time Machine 与 iCloud 和本地克隆结合起来以提高可靠性。

放宽 SMB 签名的安全权衡

在 nsmb.conf 中禁用 signing_required 是对你安全状况的真实改变，而不是表面上的切换。有必要诚实地评估你正在做的取舍。

当 SMB 签名被要求时，在你的本地网络上将自身定位为中间人的攻击者无法在传输过程中篡改 SMB 流量。没有签名，在同一二层网络上足够有动机的攻击者可以拦截 SMB 数据包，并在文件写入 NAS 时修改文件内容。攻击者需要在你的有线局域网、Wi-Fi 网络或共享同一广播域的 VPN 上。他们还需要运行 SMB 中间人工具的技术能力，这并不简单但也不罕见。

对于典型的家庭环境，拥有你控制的单一 Wi-Fi 网络、你信任的路由器，以及局域网上没有不受信任的设备，SMB 中间人攻击的实际风险非常低。家庭局域网上最常见的攻击者是在你拥有的另一台设备上运行的恶意软件，而这种情况在很大程度上超出了 SMB 签名的范围，因为恶意软件会拥有自己的凭据，不需要对你的 Mac 进行中间人攻击。

对于办公室环境、共享办公空间或任何不受信任的设备经常加入网络的场所，情况就不同了。插入树莓派的同事、带有恶意软件的访客设备或被攻陷的物联网摄像头，都可能对未签名的 SMB 流量发动攻击。在这些环境中，正确的做法不是在 Mac 上放宽签名，而是更新 NAS 固件，使签名在端到端保持必需。

一个合理的折中方案是在 nsmb.conf 中使用每台服务器的部分，仅为 Time Machine 目标的 NAS 主机名放宽签名，并将全局默认值保持为 signing_required=yes。这样，你的其他 SMB 连接仍受保护，放宽仅适用于你愿意在局域网上信任的那一台主机。

还值得注意的是，macOS 上的所有 SMB 流量默认情况下是未加密的，除非服务器明确启用 SMB 加密（这是与签名独立的功能）。如果你担心传输过程中备份内容的机密性，在 NAS 侧启用 SMB 加密比签名影响更大，而且与 26.4 回归问题无关。

等待期间的替代方案

如果编辑系统配置文件不是你理想的周末消遣方式，或者你对安全权衡感到不适，有几种替代备份策略可以并行运行或替代基于 NAS 的 Time Machine。将其中两种结合使用，可以在问题解决之前提供冗余。

通过 Time Machine 使用外接 SSD。 直接连接的 USB-C SSD 价格与单个 NAS 硬盘托架相当，可提供原生的、已签名的 Time Machine 备份，中间没有 SMB 层。2TB 的三星 T7 或 Crucial X9 Pro 可以为大多数用户保存数月的增量备份。每晚插上，让 Time Machine 完成备份，然后拔下并异地存放以防御勒索软件。缺点是需要手动操作，大多数人在两周内就放弃了。

Carbon Copy Cloner。 Bombich Software 的 Carbon Copy Cloner（CCC）可以创建 Mac 到任何目标（包括 SMB 共享）的可启动或不可启动克隆。CCC 独立于 Time Machine 处理 SMB 会话建立，并包含自己的重试逻辑，对 26.4 回归问题的抗性比 Time Machine 本身更强。许可证为一次性购买，试用期慷慨。CCC 是等待 Apple 修复 Time Machine 时寻求真实备份工具的用户的最流行选择。

SuperDuper。 Shirt Pocket Software 的 SuperDuper 是 macOS 另一款长期运行的克隆工具。它比 CCC 更简单，功能也更少，但价格也更低，对于目标仅为「在某处保留磁盘的最新副本」的用户来说已经绰绰有余。SuperDuper 写入本地目标比写入 SMB 共享更可靠，因此与外接 SSD 方案搭配使用效果很好。

Arq Backup 备份到云存储。 Arq 是一款版本化备份工具，目标是云目标，包括 Backblaze B2、Wasabi、AWS S3 和你自己的 SFTP 服务器。它专为异地备份设计，在上传前在客户端对数据进行加密，并且不依赖于 macOS SMB 栈。Arq 是本地备份的强力补充，而不是完全替代，因为大型数据集的云端恢复速度很慢。

将第二台 Mac 作为 Time Machine 目标。 如果你有一台旧 Mac，可以在上面启用文件共享，然后将主 Mac 的 Time Machine 指向第二台 Mac 上的文件夹。macOS 到 macOS 的 SMB 连接在 26.4 中仍然正常工作，因为两端使用相同的方言。这是一个小众选项，但如果硬件可用则是免费的。

在等待修复期间，大多数用户最终选择的组合是：将 Carbon Copy Cloner 作业指向 NAS，加上每周更换外接 SSD。CCC 处理每日增量工作，在 26.4 上可靠运行，而外接 SSD 提供气隙回退，可以防御从 NAS 驱动器故障到勒索软件加密网络共享的各种情况。

macOS 26.5 究竟何时修复这个问题？

Apple 于 2026 年 4 月 27 日向开发者推送了 macOS 26.5 beta 4，版本号为 25F5068a。Beta 版发布说明仍在 NDA 保密协议之下，但来自 beta 测试人员的报告证实，SMB 签名默认值已经调整，使得 Time Machine 连接到常见 NAS 配置时无需手动干预即可成功。

修复的确切机制尚未公开记录。根据 SMB 协商日志中观察到的变化，最佳猜测是 Apple 重新引入了一个回退路径，用于服务器通告签名支持但不要求的 SMB 会话，该回退路径仅限于 Time Machine 稀疏捆绑包访问。这将在保留一般 SMB 使用的安全改进的同时，为受影响的 NAS 群体恢复备份功能。

26.5 的公开发布时间线尚未确认，但遵循可预测的规律。Apple 通常在 WWDC 之前的 5 月下旬发布 macOS 主要版本的最后一个小版本，而 WWDC 2026 定于 6 月 8 日周一开始。4 月下旬的 beta 4，加上 5 月初的 beta 5 和 5 月中旬的发布候选版本，将公开发布时间定在 5 月 19 日至 5 月 26 日窗口，前后相差几天。

要深入了解 26.5 周期中的其他内容，包括新的 Apple Intelligence 功能、重新设计的提醒事项和期待已久的邮件重写，请参阅我们的 macOS Tahoe 26.5 beta 1 完整指南。

当 26.5 发布并确认 Time Machine 在不使用修复方案的情况下正常工作时，请记得删除或恢复 /etc/nsmb.conf，以便在所有网络连接上恢复 SMB 签名默认值。

故障排除清单

如果 nsmb.conf 修复方案第一次没有修复 Time Machine，在假设问题更复杂之前，请先完成以下清单。

推出并重新挂载共享。 macOS 会缓存共享的协商 SMB 会话，直到完全推出。使用 Finder 推出 NAS 共享，等待十秒，然后通过手动输入共享路径从 Finder 重新连接。只有这样才触发 Time Machine 备份。

重启 Mac。 一些用户报告说，SMB 客户端在下次启动之前不会读取新的 nsmb.conf。重启比进一步追查问题更快。

更新 NAS 固件。 即使你的 NAS 还没有针对 Tahoe 的专项修复，最新的固件更新也可能以与 macOS 更改交互的方式改进了 SMB 协商。Synology DSM 7.2.2u4、QNAP QTS 5.1.7 和 TrueNAS SCALE 24.10 是推荐的最低版本。

检查共享权限。 验证 Time Machine 在 NAS 上使用的用户账户对 Time Machine 共享具有读写权限。一些 NAS 固件更新会在更新过程中重置权限。

检查稀疏捆绑包完整性。 如果之前的备份尝试留下了部分稀疏捆绑包，手动挂载它并对其运行 hdiutil verify。损坏的稀疏捆绑包即使在 SMB 层修复后也会导致 Time Machine 失败。在严重情况下，删除稀疏捆绑包并重新开始是最干净的路径。

确认 Time Machine 目标已被识别。 打开「系统设置」>「通用」>「Time Machine」，验证目标仍出现在列表中。如果它已从列表中消失，在 SMB 层正常工作后重新添加。

检查网络连接。 从终端 ping NAS 来确认 Mac 完全可以访问 NAS。SMB 需要 IP 级连接和 SMB 端口（通常是 445）均可访问。

查看内核日志。 在备份失败后运行 log show --last 5m --predicate 'process == "kernel"' | grep smb。内核级 SMB 错误将揭示失败是在签名协商、身份验证、树连接还是文件操作层。

如果完成以上所有步骤后备份仍然失败，你特定的 NAS 固件组合可能是需要 serverMarkers.plist 方法或 NAS 侧 smb.conf 更改的特殊情况。将你的 NAS 型号、固件版本和确切的内核日志行发布到相关厂商论坛，通常是获得有效修复的最快路径。

常见问题

问：nsmb.conf 修复方案会影响到 Windows PC 的 SMB 连接吗？ 答：会。[default] 部分中的任何更改都适用于你的 Mac 建立的每个 SMB 连接。如果你想保持 Windows 连接的严格设置，请使用你的 NAS 主机名作为节名，将更改限定在每台服务器的部分中。

问：应用修复后需要重新进行完整的 Time Machine 备份吗？ 答：不需要。一旦正确建立 SMB 会话，Time Machine 将从上次中断的地方继续，写入下一次增量备份。只有在早期失败尝试损坏了稀疏捆绑包本身的情况下，才需要完整重新备份。

问：我尝试了修复方案，但 Time Machine 仍然失败。怎么办？ 答：完成上面的故障排除清单，特别注意内核日志行。最常见的后续原因是早期失败尝试留下的损坏稀疏捆绑包，而不是残留的 SMB 问题。

问：在共享办公空间使用的 Mac 上应用此修复方案安全吗？ 答：比从共享办公网络对家庭 NAS 运行未签名 SMB 更安全，但最干净的答案是要么更新 NAS 固件使服务器侧签名成为必需，要么将 nsmb.conf 例外限定在仅你的家庭 NAS 主机名。

问：每次 macOS 更新后都需要重复应用修复方案吗？ 答：/etc/nsmb.conf 文件在更新后保留。你不应该需要重新应用，除非更新专门重置了系统配置文件，这种情况很少见。

问：修复方案会破坏 iCloud 备份、AirDrop 或其他 Apple 服务吗？ 答：不会。这些服务不使用 SMB，不受 nsmb.conf 更改的影响。

问：我可以在 macOS Sequoia 或 Sonoma 上使用相同的修复方案吗？ 答：文件格式相同，相同的内容可以工作，但你不应该在 Sequoia 或 Sonoma 上需要它，因为 SMB 签名更改特定于 Tahoe 26.4。在旧版 macOS 上应用修复方案无害但无必要。

问：我的 NAS 厂商说他们有修复此问题的固件更新。我还需要保留 nsmb.conf 吗？ 答：应用固件更新并确认 Time Machine 在没有修复方案的情况下正常工作后，删除 nsmb.conf。继续保留此放宽设置是不必要的，会降低你的安全基准。

问：有编辑 nsmb.conf 的图形界面工具吗？ 答：Apple 没有官方提供。GitHub 上有一些第三方工具，但对于一个两行文件来说，终端方法比安装新实用工具更快且风险更低。

问：26.5 发布后，Apple 会将修复反向移植到 26.4 吗？ 答：Apple 没有承诺会发布解决 SMB 回归问题的 26.4.2 补丁。从历史上看，Apple 倾向于将修复滚入下一个主要小版本，而不是反向移植，特别是对于非安全性回归。将 26.5 作为解决方案来计划。

结论

macOS Tahoe 26.4 的 SMB 签名更改从安全角度来看是正确的决定，但缺乏供应商协调使得基于 NAS 的 Time Machine 备份在数周内陷入困境。/etc/nsmb.conf 修复方案简短、可逆，并解决了眼前的需求。更持久的答案是保持 NAS 固件更新，使签名在服务器端成为必需，从而在整个连接上恢复严格签名。

如果你是在 2026 年 5 月下旬或之后阅读本文，在应用修复方案之前先检查 macOS 26.5 是否已经发布。如果 26.5 可用，安装它，你的 Time Machine 备份应该无需任何系统文件更改即可恢复。如果你已应用修复方案并且 26.5 现已安装，花五分钟回滚 nsmb.conf，并确认备份在恢复严格签名的情况下仍然正常工作。

备份是只有在出问题时才会想到的基础设施，26.4 回归问题是一个有益的提醒：依赖单一备份目标是有风险的。无论你本周采取哪种修复路径，都应考虑在下一次 macOS 更新到来之前添加第二个独立的备份目标。

相关阅读

• macOS Tahoe 完整 Time Machine 故障排除指南
• macOS Tahoe 上的 SMB 和 NAS 故障排除
• 2026 年最佳 Mac 备份策略：Time Machine、iCloud 和克隆工具
• macOS Tahoe 26.4 和 26.4.1 完整更新指南
• macOS Tahoe 26.5 beta 1：新增内容与修复内容
• createinstallmedia 完整指南：回滚到干净的 macOS 安装