每次我尝试挂载 NFS 共享时,都会收到以下信息:
>> mount -t nfs gitlab-replica-storage.blah.com:/export/registry-gitlab-prod-data-vol /mnt/test
mount.nfs: Stale file handle
问题是我无法卸载,正如它所说:
>> umount -f -l /mnt/test
umount: /mnt/test: not mounted
我尝试检查是否有任何进程正在使用挂载点,但事实并非如此。
还有其他替代方法可以解决此问题吗?
作为澄清:
- 我可以将它安装在另一台机器上。
- 我无法将其安装在受影响计算机上的另一个安装点中。
答案1
如果服务器有该客户端的一些过时的导出条目,则Amount -t nfs
会失败。Stale file handle
示例场景:当服务器重新启动而客户端未首先卸载 nfs 卷时,可能会发生这种情况。当服务器返回并且客户端卸载并尝试安装 nfs 卷时,服务器可能会响应:
mount.nfs: Stale file handle
/proc/fs/nfs/exports
您可以通过查看或来检查这一点/proc/fs/nfsd/exports
。如果有客户端条目,则它可能是陈旧的条目。
您可以通过在服务器上显式取消导出并重新导出相关导出来解决此问题。例如,要对所有导出执行此操作:
# exportfs -ua
# cat /proc/fs/nfs/exports
# exportfs -a
此后客户mount -t nfs ...
应该成功。
请注意,挂载产生ESTALE
与其他一些系统调用(如 open/readdir/unlink/chdir ...)返回ESTALE
.导出过时与文件句柄过时。 NFS 很容易出现过时的文件句柄(例如,客户端有一个文件句柄,但该文件在服务器上被删除)。
答案2
ESTALE 错误最初是为了处理文件句柄(NFS 用于唯一标识服务器上的文件)不再引用服务器上的有效文件的情况而引入的。当文件在服务器上被删除时,可能会发生这种情况,无论是通过服务器上的应用程序、访问服务器的其他客户端,有时甚至是通过同一客户端上的另一个安装的文件系统。当文件驻留在不再导出的文件系统上时,NFS 服务器也会返回此错误。此外,某些 NFS 服务器甚至会在重命名文件时更改文件句柄,尽管不鼓励这种做法。
即使在客户端不知情的情况下在服务器上重新创建了同名的文件或目录,也会发生此错误。文件句柄引用文件的特定实例,删除该文件然后重新创建它会创建该文件的新实例。
当使用缓存的目录信息将路径名转换为 dentry/inode 对时,通常会出现 ESTALE 错误。当后续操作发送到 NFS 服务器时,发现该信息已过时或过时。当使用缓存信息将路径名转换为 dentry/inode 对时,这种情况很容易发生在 stat(2) 等系统调用中,但随后对服务器的 GETATTR 调用发现文件句柄不再有效。
当在查找要查找的路径名的不同部分之间或在成功查找和后续操作之间对服务器进行更改时,也可能会发生此错误。
关于ESTALE的原始链接:埃斯塔尔LWN。
我建议您检查 NFS 服务器上的文件和目录,或者告诉 NFS 服务器的管理员来执行此操作。
NFS 服务器上可能存在一些旧的 pagecache、inode、dentry 缓存条目。请清洁它:
# To free pagecache
echo 1 > /proc/sys/vm/drop_caches
# To free dentries and inodes
echo 2 > /proc/sys/vm/drop_caches
# To free pagecache, dentries and inodes
echo 3 > /proc/sys/vm/drop_caches
答案3
就我而言,在安装新卷时,我还收到错误“mount.nfs:过时的文件句柄”。这是因为安装的旧卷被删除后发生的。卸载后,使用的卷,
umount /mnt
当我再次安装时,问题就解决了。
答案4
检查导出是否实际挂载:
# cat /proc/mounts | grep nfs
过时文件句柄错误意味着 NFS 服务器在其导出路径中保存了旧版本的文件。重新启动 NFS 服务器有时会有所帮助。但对于较旧的操作系统 (RHEL/CentOS 6.9),有时最好恢复到 NFS3 而不是 NFS4。根据我的经验,较旧的 NFS4 客户端有时会在使用较新的 NFS4.1 服务器时遇到困难。对于文件锁定尤其如此。