问题陈述（注意这个问题已经解决了，但是有一个问题是为什么这个解决方案有效）
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 文件处理程序，但在重新启动后仍然存在似乎很奇怪。
答案1
简而言之，fsid 是客户端和服务器在安装导出后识别导出的方式。
正如手册页所述，如果未指定，fsid 将从底层文件系统派生。
四个导出具有相同的 fsid，因此当 client1 询问其挂载的文件时，服务器可能会认为它正在尝试访问 client4 的导出（假设它仅保留最新出现的相同 fsid）。
我想有几种方法可以验证这个假设，例如检查 4 个客户端中的一个（且只有一个）是否有效。另外，仅保留 client1 导出，而不保留其他 3 个导出，并确认 client1 可以正常工作。
也可以看看这个答案有关从客户端查询 fsid 的方法，请使用以下mountpoint -d命令，您可以从 4 个客户端使用该命令来确认 4 个安装具有相同的 fsid。
为什么这是一个解决方案？
因为使用不同的 fsid，导出对于 NFS 服务器来说将是不同的，因此它将正确地将客户端访问与其相应的安装相匹配。
我们应该在每次导出时使用 fsid 吗？
是的，我认为这是一个很好的做法，它可以确保您保持对底层存储设备的控制和更改，并且导出不会影响您的客户。
（就我而言，我记得采用它是因为我的一些磁盘位于 SAN 上的 NFS 服务器有时会以不同的顺序扫描磁盘，因此重新启动后 /dev/sdh 会突然变成 /dev/sdj。使用标签挂载可确保它会安装在正确的位置，但 fsid 会改变，客户端会丢失，这是在 UUID 普遍存在之前，UUID 显然现在受到支持，并且当然是一个更好的解决方案，当磁盘出现问题时不会损坏。但是，显式指定 fsid 并不是一个坏主意，可以让您保持完全控制。）
答案2
我在运行 Ventura 13.2 的 Mac 上通过 NFS 访问 QNAP 时遇到了这个问题。结果是一个陈旧的 NFS 句柄，尽管重新启动两个设备，该句柄也不会消失。
要确认，只需登录服务器ssh并执行以下操作
exportfs -ra
没有任何其他东西（没有配置更改，没有玩fsid，没有其他操作）就让问题消失了。