在 Mac 上通过 VPN 访问 SMB 共享：先连接，再测试写入
Finder 能挂载共享却拒绝保存？先分清 VPN 路径、SMB 帐户和服务器权限，再改动任何设置。
如果 Finder 通过 VPN 挂载了共享，却拒绝保存文件，说明隧道本身已经在工作，分歧出在文件服务器上的身份与权限。如果连挂载都不出现，那么这条链路之后的部分都还没有被验证。两种情况在 macOS 上会弹出看起来差不多的对话框，于是人们为一个 VPN 根本无法制造的故障去重建 VPN 配置文件。我先确认连接究竟停在哪一环，然后才用一次性文件测试写入，而不是直接动那份准备编辑的文档。
三个条件决定该查哪一层
在碰任何设置之前，你需要三个答案：名称能否解析到隧道所路由的私有地址，SMB 服务是否接受你提供的那个具体帐户，以及该帐户在那一个共享、目录和操作上是否拥有写权限。三者失败的位置各不相同，只有第一个属于 VPN 管理员的责任。
| What you see | What it establishes | Who fixes it |
|---|---|---|
| Name does not resolve, or resolves outside the tunnel | The path was never built | VPN or DNS administrator |
| Name resolves, port 445 times out | Route, firewall or overlapping address space | VPN and network owners |
| Server answers, the sign-in is rejected | The file-service account, not the VPN login | File-server owner |
| Share mounts, writing is refused | Share policy or directory rights | File-server owner |
这张表值得占一席之地，因为 Mac 登录、VPN 登录和 SMB 帐户是三个彼此独立的身份。改 VPN 密码永远不会打开一个拒绝注册用户的共享；客户端报告已连接，也说明不了你所指向的那台服务器。
靠地址连接，而不是靠浏览
远程共享完全可达，却可能始终不出现在 Finder 的网络列表里。办公局域网里的发现依赖广播与多播名称，而多数 VPN 不会把这类流量带过隧道，所以网络列表为空并不能证明链路坏了。
用常规客户端启动目标 VPN，并完成它的身份验证。
在 Finder 里选择“前往”，再选“连接服务器”，或按 Command-K。
输入给定的地址。本例中是
smb://files.corp.example/team，一个示例名称，而非公共服务。如果你只有服务器名，就连到它，再从它返回的列表里挑选被授权的共享。选择“注册用户”并输入文件服务帐户，不是你的 Mac 帐户，也不是 VPN 帐户。只有在所有者明确这么说时，来宾才合适。
打开共享，完成你真正要办的那一件事。目录列表只能证明挂载成功，别的什么也证明不了。
Apple 的 连接服务器指南 记录了这套 Finder 流程以及其背后的服务登录。把地址存为个人收藏，下次连接才可复现；也请记住，重命名条目只改标签，不改目标。
读出它停在哪一步
在改动任何东西之前，先记录是哪一步失败，用的名称要与你在 Finder 里输入的一致。从名称解析开始： dscacheutil -q host -a name files.corp.example 会打印 macOS 将要使用的地址，而 netstat -rn 则显示该地址是否经由隧道接口或家庭网关有路由。
然后是可达性。 nc -vz files.corp.example 445 说明 SMB 端口是否真的有回应；如果解析正常而 445 超时，你就在路由、防火墙或地址重叠的地带，改共享权限帮不上忙。如果端口有回应，再问服务器它为那个帐户提供了什么： smbutil view //[email protected] 会列出共享，而 smbutil statshares -a 会报告已挂载会话协商出的方言与签名状态，由此可以判断你正在测试的挂载是不是你以为的那个。
身份值得单独检查，因为这一步最常被跳过。你以为自己是注册用户，挂载却可能以访客或某个旧的已存帐户在运行，那么每次写入测试量的都是错的帐户。
写权限不止一道门
服务器一侧有两层可以说“不”，而从 Mac 看过去长得一模一样。共享可以以只读方式导出，而它下面的目录却可写；可写的共享也越不过一条拒绝你帐户的文件系统 ACL；子目录还可能带着自己的策略。在 Windows 服务器上，共享权限与 NTFS 权限是分开的，最终生效的是两者中更严格的那个。
所以先确定到底被拒绝的是什么：新建文件、编辑已有文件、创建目录、重命名，还是删除。这些不是同一个权限，而一个能列目录的文件夹可能把它们全部拒绝。能挂载不等于被授权。
如果怀疑身份不对，请卸下共享，删除“钥匙串访问”里的旧条目，再用注册帐户重新连接。Finder 会乐于复用已保存的会话，让你去为一个服务器并不认为是你的人测量权限。
在不碰真实文件的前提下测试写入
征得所有者同意后，在那个失败的目录里用新名称建一个小文件： touch /Volumes/team/qa-write-test.txt 当共享挂在那里时可以直接这样做，或者干脆从应用里“另存为”一个新名称。永远不要靠覆盖文件来测试访问，并且保留错误的原文，不要改写它，因为 VPN 不会把它复制过去。
然后把尝试过的操作交给所有者，而不是一句笼统的抱怨。他们可以检查共享策略、帐户的组成员关系以及那一个目录上的权限，并告诉你是哪一层拒绝了你。如果提示里提到容量、文件被锁定或名称冲突，那是另一个问题，值得单独排查。
确认修复有效，然后按顺序卸载
所有者改动之后，重复同一次小写入，并确认服务器能看到这个文件、之后也能删掉。开始后卡住的复制是吞吐问题，不是权限问题；立刻返回的拒绝才是权限问题。
断开 VPN 之前，先卸载共享并关闭打开的文档。隧道消失后再弹出，会让 Finder 和你的应用等在一个已经死掉的路径上。把 SMB 留在内网，不要为了验证猜想而关掉防火墙，也不要图省事把一个目录开放给所有人。写工单时附上地址、帐户名、失败的操作、提示原文和时间，把密码和配置文件留在外面。
- 该地址解析成经由隧道路由的私有地址。
- 445 端口有回应，且
smbutil view为那个帐户列出了预期的共享。 - 你需要的写入由一个新建文件来证明，而不是由一份已有文档来证明。