服务器A曾经是一个NFS服务器。 服务器B正在挂载一个导出。 一切（曾经）都很好。 然后A死了。 刚刚关掉。 不见了。 消失了。
然而，该文件夹仍然安装在B.我显然不能cd到它或任何东西。 然而， umount /mnt/myfolder只是挂起，不会卸载。 无论如何卸载它，而无需重新启动B？
客户端和服务器都是Linux机器。
假设Linux：
umount -f -l /mnt/myfolder
会解决这个问题：
-f强制卸载（在无法访问的NFS系统的情况下）。 （需要内核2.1.116或更高版本。）
-l懒惰卸载。 现在，从文件系统层次结构中分离文件系统，并在文件系统不再忙的时候立即清除对文件系统的所有引用。 （需要内核2.4.11或更高版本。）
-f也存在于Solaris和AIX上。
详细阐述了David Pashley的提示，
除非“umount -l”解决了你的问题，否则你可以设置一个伪造的服务器，其地址与去掉的地址相同 – 但实际上并不需要build立一个新的服务器或任何东西。 阻塞/挂起umount情况的最简单的方法是build立一个本地别名IP接口 ，如下所示：
ifconfig eth0:nfstmp 11.22.33.44 netmask 255.255.255.255 umount -l /mnt/deadnfsmount # -l or -f or whichever that gets the job done ifconfig eth0:nfstmp down
（显然11.22.33.44是（现在已经死的）NFS服务器的（以前的）IP地址）
将intr选项添加到可能最终挂起或崩溃的任何/etc/fstab条目可能是明智的做法。 如果您不使用soft或intr选项，则当托pipeNFS文件的服务器出现故障时，启动时挂载文件的服务器（客户端）可能会挂起。
根据man 5 nfs ：
软硬
确定NFS请求超时后NFS客户端的恢复行为。 如果没有指定任何选项（或者指定了硬选项），NFS请求将无限期地重试。 如果指定了soft选项，则NFS客户端在重新传输重新发送之后，会失败NFS请求，导致NFS客户端向调用应用程序返回错误。
然后它继续说intr比soft更intr ，但它具有类似的防止挂的效果。
umount -f /mnt/myfolder应该解决这个问题。 请参阅卸载联机帮助页。
就像旁边一样，使用automount将会处理卸载NFS共享，当它们变得不可靠时，避免将来陷入这种情况。
我从来没有设法让umount -f工作。 一个有用的技巧是设置另一个服务器挂载相同的导出，给它与旧服务器相同的IP地址。 你的NFS客户端应该认为一切正常，进程将被解除阻塞。 然后，您可以正常卸载挂载点，并从临时NFS服务器中删除IP地址。
对于Solaris，重新启动NFS客户端将解决“硬死亡螺旋”。 Solaris 10的命令是“svcadm restart network / nfs / client”最近没有在Linux上试过这个（因为这些都是用“intr”标志挂载的，所以他们很less遇到这个问题），但是它可能也会修复问题。
我只注意到强制卸载内核3.2.0挂起NFSv4挂载。 NFSv3卸载工作正常。
$ mount [...] -o nfsvers=3
只是一个OS X特定的后续，因为mount命令主要是* nix不可知的：OS X中不存在-l（懒惰）标志，然而，-f（强制）标志确实是足够的。 此外，系统生成的挂载点位于/ Volumes（/ Volumes / myserversexport）