NFS故障：Stale NFS file handle的解决一例

故障描述：一台备份一体机设备作为NFS服务端，export了目录/infokit/exportnfs，从其他设备上挂载这个NFS 目录，在NFS服务端和客户端及其上showmount -e 都一起正常，挂载的时候提示“Stale NFS file handle”。

调试过程：在NFS服务端上，export了另外一个目录 /home/share，从其他设备挂载正常，判断问题出在“/infokit/exportnfs”上面，一开始总是怀疑权限问题，但chmod 777也不行证明不是。

解决方法：/etc/exports文件中，加入fsid=0参数

/infokist/exportnfs/ *(fsid=0,rw,sync,no_subtree_check)

然后重启服务后，客户端挂载正常

exportfs -rv
service nfs-kernel-server restart

---

一、关于Stale NFS file handle错误信息

从字面意义是指失效的文件句柄，文件变得不可用了，使用ls， stat，cat等等命令去查看文件的时候会发现无法看到文件的任何信息。

文章《Stale NFS file handle 问题分析和总结》分析了从代码角度的意义，也就是文件的Link count计数不对导致的这个问题，对linux系统来说，文件的引用计数为0表示文件被删除了，占用的inode节点要被回收，被它所在目录要去除改文件的目录项。

二、 问题原因及解决方案

上述情况有下面几种可能的出错原因，大部分网上文章谈的是第一种。

1. 客户端mount问题

有的时候，NFS Client已经mount上的文件或者目录，在NFS Server上突然被remove或者unexport，就会出现这样的信息。例如NFS Client端mount上了NFS Server端的目录后，如果NFS Server端把这个目录进行了unshare。就会在NFS Client端出现这个错误。

解决办法：在NFS Client上取消文档或者目录的挂载。用fuser或者lsof|grep 查找占用NFS共享的目录或者文件的进程，然后杀掉进程，再强制umount卸载掉NFS Client上已经mount的文件目录，重新挂载即可。

fuser -m -v $file_path

kill -9 $PID

umount -f $file_path

2. 文件系统损坏

《Stale NFS file handle 问题分析和总结》提到NFS服务端如果是ext2的话容易出现这种问题，可以fsck进行修复，对于xfs文件系统，xfs_repair进行修复。

3. XFS文件系统输出NFS的问题

《解决XFS文件系统NFS输出Stale NFS file handle错误》提到XFS官网的文章http://xfs.org/index.php/XFS_FAQ

所涉及的场景和本例是接近的，也就是说

“XFS默认（使用inode32）会把inodes（索引节点）放在硬盘的前1TB容量上，如果你有100TB的硬盘，所有的inodes都会挤在前1TB里，这会导致奇怪的事情（例如磁盘已满）发生，即使你还有大量空间，因为不能在前1TB的空间上创建新的索引节点，同时，性能也会急剧下降。为了避免这个问题，请使用inode64的挂载选项，inodes将会被放在数据存在的位置，最大限度的减少硬盘寻道。”

fsid是NFS用来识别自身导出的每个文件系统的，通常情况下，NFS会使用设备的UUID或者文件系统上的设备数量来当作fsid；有时候，有的文件系统并没有UUID，或者并非所有的文件系统都是直接存放在设备上，因此，需要明确指定fsid以便NFS可以识别一个文件系统；默认的fsid类型只为二级目录准备了32位的inode数量，所以，解决方法为，导出文件系统的根分区，或者使用非默认的fsid类型。

解决方案两个：

1，挂载XFS分区时，添加inode64参数。否则会默认使用inode32来挂载。
2，本地目录通过NFS export时，记得添加fsid=XX参数。

fsid的理解参考《【NAS】NFS中的fsid如何理解》

本例使用fsid=0参数解决（使用fsid=0选项的时候只能共享一个目录，这个目录将成为NFS服务器的根目录。），过程如下：

下面是这台输出NFS服务的存储上的分区情况，可见/infokist挂载在一个33T的XFS分区。

root@infokist:/# df -T -h
Filesystem                        Type      Size  Used Avail Use% Mounted on
udev                              devtmpfs   16G     0   16G   0% /dev
tmpfs                             tmpfs     3.2G   18M  3.1G   1% /run
/dev/mapper/rootvg-rootlv         ext4       30G  6.8G   21G  25% /
tmpfs                             tmpfs      16G     0   16G   0% /dev/shm
tmpfs                             tmpfs     5.0M     0  5.0M   0% /run/lock
tmpfs                             tmpfs      16G     0   16G   0% /sys/fs/cgroup
/dev/sda1                         ext2      472M   78M  370M  18% /boot
/dev/mapper/infokistvg-infokistlv xfs        33T  7.6T   26T  23% /infokist

没有加入fsid=0之前，/infokist/exportnfs/  *(rw,sync,no_subtree_check)，客户端挂载现象如下（有的时候挂载提示失效文件句柄，有的时候挂载上去列目录出现不能识别）

[root@backupDK mnt]# showmount -e 192.168.0.35
Export list for 192.168.0.35:
/home/exportnfs     *
/infokist/exportnfs *
[root@backupDK mnt]# mount -t nfs 156.18.0.35:/infokist/exportnfs /mnt/infokist
[root@backupDK mnt]# ll
ls: 无法访问infokist: 失效文件句柄
总用量 0
drwxr-xr-x. 2 root root 6 10月 30 2019 cdrom
drwxr-xr-x. 2 root root 6 12月  9 19:35 db
d?????????? ? ?    ?    ?            ? infokist

在/etc/exports中，加入fsid=0参数：

/infokist/exportnfs/ *(fsid=0,rw,sync,no_subtree_check)

客户端可以正常挂载和使用（挂载的目录权限也是正常）。

[root@backupDK mnt]# umount /mnt/infokist
[root@backupDK mnt]# mount -t nfs 156.18.0.35:/infokist/exportnfs /mnt/infokist
[root@backupDK mnt]# ll
总用量 0
drwxr-xr-x. 2 root root   6 10月 30 2019 cdrom
drwxr-xr-x. 2 root root   6 12月  9 19:35 db
drwxrwxrwx. 2 root root 186 12月  9 11:59 infokist