VPN 断开后的 SMB 共享：一份恢复检查清单
先停止写入，再恢复真正的服务器路径，并把失败的保存视为未知而非丢失。已打开的句柄不会在新一次 VPN 会话中存活。
保存卡住，隧道断开，三十秒后 VPN 重新连上，Finder 窗口却仍在一个空的共享上转圈。一切看起来都该正常工作。隧道是通的，网络是通的，卷却不是。请按顺序处理，因为在一个应用仍认为自己握着打开句柄时重连，正是把不确定的写入变成丢失的写入的那条路。
先从停止对共享的操作开始，而不是先重连。这显得有些被动，但保护数据的恰恰是这一步。
重连之前先停止写入
关闭所有正在主动尝试写入的东西，并尽可能通过应用自身的保存或恢复路径把内容存到本地。不要启动大体积复制，不要让同步客户端无休止地重试，也不要接受把服务器副本替换为你本地副本的提示。真正让数据受损的正是第三条指示，因为超时的保存既未确认、也未必不存在，而覆盖服务器上的文件会抹掉唯一能说明究竟发生了什么的那份证据。
如果应用显示同一文档的两个版本，先都留在原处。按文件名或时间戳挑一个赢家，是披着决定外衣的猜测。
先恢复路径，再验证它
重新连接目标的 VPN 并完成认证，然后确认文件服务器的名称能解析，且 SMB 服务能通过隧道应答。已连接这一状态只描述隧道，所以要把它当作检查的起点而不是终点。
确认文件服务器经隧道能够解析名称并可以访问。
在创建另一个挂载之前，先给现有挂载一分钟；同名的第二个卷比一次慢速恢复更难判断。
如果卷没有回来，就有意通过 Go、再走 Connect to Server，用服务器的已知地址连接，例如
smb://files.corp.example/team。用文件服务器账号登录，这是 一项与 VPN 登录分开的凭据决定，并在继续之前确认应用中的文档状态。
Apple 的 Finder 连接指南 记录了显式地址的方法，这里可靠的也正是它。侧边栏里的卷名只是一份缓存的标签，不是上一次连接仍然可用的证据。
为什么新会话无法保证打开句柄
SMB 确实有熬过临时断开的一套机制，而两者都是条件性的。持久打开可以在客户端与服务器协商出的时间窗内被重连，而持续打开需要双方具备更严格的能力。Mac 客户端与文件服务器同意挂载一个共享，并不说明你已打开的文件协商到了其中哪一种机制。
规范对失败同样说得很清楚：恢复不成功时，句柄被作废，客户端应当把该文件视为已关闭。那一刻正写到一半的应用没有可继续的有效句柄，哪怕共享又能浏览、文件在 Finder 里看起来完好。
所以重新出现的卷是必要的一步，而不是充分的一步。编辑器、数据库类应用以及任何持有独占锁的东西，可能需要重新打开自己的连接；而关于文档状态的唯一可信报告来自应用，而不是文件列表。
不要为了好看而强行整理挂载
为了清掉卡住的侧边栏而强制卸载卷、或杀掉文件系统辅助进程，看起来诱人，通常适得其反。卡住的状态往往反映一个真实在等待的操作，把挂载从它下面抽走，并不能把应用的数据安全送到任何地方。这还会让接下来的排查更难，因为用户看到的报错已经被从屏幕上清掉了。请记下应用报出的确切错误和断开的时间，正是这个时间戳能让你把自己的报告与服务器日志对上。
如果共享一直繁忙，请走文件服务或 Mac 支持的流程，而不是升级为强攻。保留证据比一个干净的侧边栏更值得。
在下一次计划内的断开之前
有意断开 VPN 之前，先完成保存、关闭依赖的文件，并正常推出共享。这个顺序很廉价，却能消除整类问题。
对于经常遭遇中断的工作，改变的是工作模型而不是挂载：保留一份本地副本，并通过应用支持的机制同步，这样隧道掉落只让你损失一个同步间隔，而不是一次不确定的写入。挂载脚本无法保住任意打开文件的事务，再怎么调整也不会让它去尝试。