问题陈述（注意这个问题已经解决了，但是有一个关于为什么解决方案有效的问题）
NFS 服务器是 Ubuntu 16.04.4 LTS。客户端是 Ubuntu 16.04.4 LTS 和 CentOS 6.10 和 7 的混合。
NFS 服务器几个月来一直运行良好，其中一项特殊的导出服务是为多个客户端提供备份服务。NFS 服务器目录如下所示：
/mnt/backups/client1
/mnt/backups/client2
/mnt/backups/client3
/mnt/backups/client4
/etc/exports 包含：
/mnt/backups 1.2.3.0/24(rw,sync,no_subtree_check)
客户端仅在备份期间挂载 nfs 服务器，然后在完成后卸载备份。
这工作正常，但是，确定客户端不应该能够在 /mnt/backups 目录中看到彼此。每个客户端都使用相同的备份 uid/gid。因此，决定通过使用 /etc/exports 文件来分离目录。
为此，NFS 服务器已停止，并且 /etc/exports 已修改，因此它包含：
/mnt/backups/client1 1.2.3.21(rw,sync,no_subtree_check)
/mnt/backups/client2 1.2.3.22(rw,sync,no_subtree_check)
/mnt/backups/client3 1.2.3.23(rw,sync,no_subtree_check)
/mnt/backups/client4 1.2.3.24(rw,sync,no_subtree_check)
回想一下，客户端仅在进行备份时（凌晨 4 点）才挂载 NFS 服务器。在服务器上重新启动 NFS 服务，并使用 exportfs 检查导出，看起来不错。
好的，测试client1：
mount nfserver:/mnt/backups/client1 /mnt/client1
工作正常，但是，对 /mnt/client1 的任何操作都会导致：
cannot open directory /mnt/client1/: Stale file handle
采取的解决措施（无效）：在服务器上重新启动 NFS。重新启动客户端。lsof |grep /mnt 在客户端和服务器上查看是否有任何程序保持打开文件。服务器/客户端的权限检查。同样，将 NFS /etc/exports 切换回旧文件并从客户端挂载 nfs 服务器可以正常工作。切换回“新”方法不起作用。
经过大量的咬牙切齿、手册页和 STFW 只是为了找到像“重新启动 NFS”这样的答案，我回忆起几年前我遇到了这个问题，出于某种原因 fsid 与解决方案有关。阅读手册页后，在 NFS 服务器 /etc/exports 文件中添加了以下内容：
/mnt/backups/client1 1.2.3.21(fsid=101,rw,sync,no_subtree_check)
/mnt/backups/client2 1.2.3.22(fsid=102,rw,sync,no_subtree_check)
/mnt/backups/client3 1.2.3.23(fsid=103,rw,sync,no_subtree_check)
/mnt/backups/client4 1.2.3.24(fsid=104,rw,sync,no_subtree_check)
同样，在此操作之后，唯一执行的操作是在服务器上执行 exportfs -ra。
现在所有客户端都可以挂载 nfs 服务器导出并且它们都可以工作。
为什么这是一个解决方案？
我们应该在每次导出时使用 fsid吗？
阅读像这样的手册页似乎并不能清楚地解释为什么 fsid 是一种解决方案。我有一个想法，可能是陈旧的挂载是客户端（或者可能是服务器端）上的某种 NFS 文件处理程序，但是在重新启动后仍然存在这种情况似乎很奇怪。