我昨天遇到一个连接丢失的服务器（S1）。 从该服务器，有一个共享与另一个（S2）的NFS目录，没有homedir，不在$ PATH，但一个目录，存储旧文件的归档。 S1在几个小时后又回到了在线状态，但现在我不能访问S2了（因为这一点，我相信是因为所有其他的服务没有任何问题）。 ssh连接挂在这里：debug1：进入交互式会话。 我知道重启会做这个工作，但考虑到这是一个大应用程序的NAS，我的老板会杀了我，如果我这样做。 有没有其他办法克服这个？ 我尝试了不同的用户，但他们都挂在同一个地方。 我与HP iLO连接，甚至没有我不能使用我的用户名。
提前致谢。
（你不可能在S2上自动挂载目录，是吗？）
尝试使用ssh而不使用交互式会话：
$ ssh -tvv you@S2 /usr/bin/env MAILCHECK=0 MAIL=/dev/null MAILPATH=/dev/null sh “-vv”有ssh打印额外的输出 – 不能伤害 – “-t”告诉它分配一个TTY，即使它运行一个命令，而不是启动一个交互式shell。 命令env将一堆MAIL *环境variables设置为空，这对于了解是否有NFS上的邮件，然后最后启动一个简单的shell是有用的。
或者，如果合适的话，尝试HOME=/ /bin/su -而不是sh 。
如果你确实进入，肯定会尝试卸载NFS挂载。 如果失败（可能），请使用-f尝试。 如果失败（可能），Linux有一个懒惰卸载的-l选项：它将从文件系统树中分离挂载点，这将使任何新的进程响应。 任何现有的进程仍然会被挂起，除了重启之外，没有任何办法。
如果我读取了你的消息报告：一个用户正在尝试ssh到user @ S2 S2从S1 S1挂载一个文件系统，之前有一个问题导致在S2上发生NFS错误。 安装在S2上的文件系统不是主目录。
你在使用自动加载器吗？ 这是Linux还是其他一些UNIX的味道？
这种types的问题是有意义的，如果缺less的NFS挂载是一个主目录或在用户的login过程中以某种方式访问 – login过程试图访问该目录，并陷入磁盘等待。 随着身份validation的成功，几乎必须成为这些问题之一。
所以你是1000％确定用户的主目录不是NFS？ 如果不是，则应该能够通过以root身份login系统来读取S2上的用户的点文件，并检查与有问题的NFS文件系统交互的任何实例
您应该可以通过以root身份（通过iLO控制台，如果没有别的）login到系统进行validation，并执行以下操作：ps auxww | grep D
你可以以root身份进入系统吗？ 还是有什么我不明白？
强制卸载，然后重新启动在S2的NFS进程，然后重新安装应该解决这个问题，虽然你可能有一堆滞留，直到重新启动不会消失。