VPN 上的 SSHFS 挂载应由用户会话拥有吗？

root VPN 钩子无法借用桌面代理。以已登录用户的身份挂载，把触发器限定在一个连接上，并在强制卸载前做好规划。

VPN 启动后挂载共享文件夹涉及两个容易混淆的身份： 有权配置网络的组件，以及有权登录文件服务器的账户。两者很少相同。root 所有的 VPN 钩子不适合作为桌面用户 SSHFS 挂载的起点，因为它既没有用户的代理，也没有预期的挂载所有权。先把所有权确定正确，触发器就会变得简单。

两个身份，两套独立权限

VPN 客户端需要权限来更改路由和接口。SSHFS 挂载需要文件服务器接受的 SSH 身份，以及由将要读取文件的账户所拥有的 FUSE 挂载。一个以 root 运行的脚本满足了第一个要求，却悄悄破坏了第二个。

以 root 挂载会让文件留在桌面会话之外，而且可能无法访问持有用户密钥的代理。挂载存在，用户却无法通过它写入，故障看起来像服务器端的权限问题。这种误诊会耗费一个下午，还会给存储团队开一张工单。

在编写任何自动化之前，先确定哪个账户拥有挂载，因为这个选择决定了触发器住在哪里，以及它能触及哪些凭据。

先手动建立用户所有的挂载

从一个已登录用户开始，准备空挂载点、已授权的 SSH 账户，以及经隧道通往服务器的可用路径。手动挂载确立了任何自动化都必须复现的基线。

mkdir -p "$HOME/mnt/team"
sshfs [email protected]:/exports/team "$HOME/mnt/team"
mount | grep sshfs

这些名称只是示例，请替换成你的服务器实际提供的主机和导出路径。首次连接时通过已批准的流程验证主机密钥。注意，VPN 账户密码并不自动就是存储账户的凭据，这是尝试失败的常见原因。

以普通用户身份运行，并使用该用户拥有的挂载点。默认情况下只有执行挂载的账户能访问文件，而 allow_other 会把这一边界扩大到每个本地用户。这是有意的访问扩展，不是为自动化开的旁路。

让触发器在同一会话上下文中执行

让受支持的 VPN 事件集成请求执行用户会话操作，而不是假设特权回调可以借用桌面凭据。把触发器限定在预期的连接标识符上，而不是任何恰好名为 tun0 的接口。匹配错对象的调度规则会在每次网络变化时触发，包括与本次挂载毫无关系的变化。

该操作应确认预期主机名、发现已有挂载，并只做一次有界尝试。每隔几秒启动一个新 SSHFS 进程，或在服务器宕机时反复请求凭据的轮询循环，会把短暂中断变成一堆卡住的进程。用超时和一次重试来限制尝试。

nmcli -g UUID connection show --active
systemctl --user list-units 'sshfs*'
pgrep -a sshfs

第一条命令给出调度器应当匹配的连接标识符。另外两条显示是否已有尝试在运行，这正是防止重复的检查。

无人值守服务需要自己的已批准凭据，并在自己的执行上下文中进行主机验证。它不能假定图形代理已解锁，也不应尝试解锁一个。

在强制清理之前规划断开

对于计划内断开，先完成文件操作，并从执行挂载的用户自己的工作流中卸载。以挂载点而不是进程为目标，并在报告成功前确认结果。

fusermount3 -u "$HOME/mnt/team"
mountpoint "$HOME/mnt/team"

只卸载此工作流创建的挂载。如果它忙，那是应用层的决定：为了钩子返回成功而存在的强制分离，只会掩盖数据丢失，而不是防止它。

意外丢失的表现不同。SSHFS 文档说明网络中断可能阻塞文件系统操作，而 reconnect 选项会恢复传输却不恢复句柄：重连前打开的文件可能在下次写入时失败，中断的写入也不会保留。这一区别对长时间打开同一个文件的编辑器最重要。要规划重新打开的步骤，而不是假定恢复。

在依赖它之前，用一次性文件测试行为。隧道恢复后目录重新出现，并不能证明先前的句柄或未保存的工作幸存下来。

相关文章