时不时地，当用户从他们的 OS X（Snow Leopard）工作站通过 SSH 连接到我们的一台 Linux 主机时，他们会收到以下消息：
/usr/bin/xauth: ~/.Xauthority not writable, changes will be ignored
当然，他们的X转发应用程序此时将无法工作。
但是，如果他们注销并重新登录，他们就不会收到消息，并且一切都按预期运行。
在 Mac 上，他们通过 AFP 获取主目录。在 Linux 上，他们通过 NFS 获取主目录。
对于这里可能发生的事情有什么想法吗？
答案1
我不禁想知道您是否看到了竞争条件，也许是这样的：
- 用户登录 OS X 客户端，通过 AFP 安装主文件夹
- 用户
ssh进入 Linux 主机，该主机装载了 OS X 客户端已装载的主目录，但是通过 AFP 执行。 - Linux 主机读取（写入？）~/.Xauthority 并且文件被锁定 - 要么是故意的（作为检查过程的一部分），要么不是（服务器这样做是为了防止两个系统使用不同的协议写入同一个文件，或者，防止两个不同的系统同时侵犯一个文件，无论使用什么协议）。
- 原始 Mac OS X 客户端想要记录有关会话的数据 [题外话：我真的不知道 .Xauthority 是用来做什么的] 并尝试访问该文件
- 提示文件已被锁定
- 大约在这个时候，Linux 机器已经处理完了这个文件，并且它被解锁了
在另一个尝试中，情况可能是这样的：
1) 它们正尝试连接已知主机，而 OS X 客户端不需要记录任何信息，也不访问 .Xauthority，或者 2) 时间已经足够长，两个系统不会尝试同时使用同一个文件 [因此这是一种竞争条件]。
我不确定你如何判断是否是这种情况。我认为你可以fs_usage在服务器上使用命令（或 GUI 工具，如七人) 来查看是否正在快速连续地访问同一个文件，尽管这并不一定能证明什么。
您可能能够通过lsof在文件或（lsof -i）网络连接上使用 来收集有用的信息。也许您可以打开 AFP 和 NFS 的日志记录（或使用nfsstat?）并交叉引用它们。
我会考虑编译伊夫托普但是，运行它时您应该看到的是，是的，Mac 客户端和 Linux 客户端都连接到了服务器，并且它们使用不同的端口并传输信息。
我建议让测试用户在 Mac 客户端和 Linux 主机上使用不同的帐户进行 ssh 一段时间，看看他们是否会出现问题。如果没有，那么这确实与同时在两个地方使用同一个帐户有关（很可能是由于两次挂载主文件夹）。
可能值得看看您是否可以配置 OS X 和 Linux 以使用 Xauthority 文件的不同副本。（我不确定您是否可以做到这一点）。
我还会尝试让测试用户通过 NFS 访问 OS X 上的主文件夹，看看是否有区别。
答案2
很久以前，我曾通过 ssh 启动过几十个 X 应用程序。ssh 使用 xauth，它本身会锁定 .Xauthority 文件，如果无法锁定，就会失败。当时通过修改 xauth 程序来解决这个问题，改为旋转锁，但现在没有补丁了。
答案3
如果 ssh_config 文件没有设置 ForwardX11，你可能必须在 ssh 命令中使用 -X。IE 看看
ssh -X 机器名
作品