NFS挂载目录原本可用，随后执行ls、读文件或进入子目录时出现Stale file handle。这表示客户端保存的句柄已经不能在服务器端还原成原来的文件对象。
重试同一条命令通常不会修复失效句柄，应先确认服务端发生了什么变化。
Stale file handle具体表示什么
Linux内核NFS文档说明，服务器用文件句柄定位导出的对象；当服务器无法把句柄解析回对应目录项时，会向调用方返回ESTALE。文件、目录或底层文件系统被替换后，旧客户端仍可能持有已经失效的句柄。
它不同于网络超时：服务器可能在线，但旧句柄所指对象已不可识别。
先检查服务端最近的变更
核对NFS服务器是否重建了导出目录、替换或重新格式化了文件系统、调整了集群文件系统标识，或者删除后重新创建了同名目录。若启用了文件句柄签名，内核文档指出更换签名密钥也会使现有客户端句柄立即失效。
同名路径不等于同一个文件对象。删除后重建的目录可能拥有新的inode和句柄。
客户端怎样确认影响范围
使用findmnt -T 挂载点和mount确认服务器、导出路径与挂载参数，再检查dmesg或journal中的NFS错误。分别访问挂载根和具体子目录，判断是单个路径失效还是整个导出失效。
不要在故障挂载上运行递归扫描或备份任务。它们可能长时间阻塞并扩大应用影响。
如何安全卸载并重新挂载
先停止使用该挂载点的应用、容器和定时任务，确认没有进程把当前目录或打开文件留在其中，再执行正常umount并按已核验的/etc/fstab配置重新挂载。若普通卸载失败，应先找出占用者，而不是直接强制或懒卸载。
umount -l只会从目录树分离挂载，旧引用仍可能存在，不能替代应用停写和正常恢复。
重新挂载后的验收标准
重新挂载后检查挂载源、NFS版本和关键参数，验证创建、读写、重命名与权限行为，并重启依赖服务。可在萤光云或LightNode的测试VPS演练服务端目录替换。验收标准是ESTALE消失、应用不再持有旧引用、关键数据来自正确导出，并且主机重启后仍挂载到同一服务端文件系统。
FAQ
问：设置noac可以避免Stale file handle吗？答：noac主要改变属性缓存和写入行为，代价较大，也不能让服务器重新识别已经失效的文件句柄。
问：可以直接重启客户端吗？答：重启会清除旧挂载状态，但影响更大。能安全停止应用并正常重新挂载时，不必先重启整台主机。
温馨提示
温馨提示：更换NFS后端、导出目录或文件句柄签名配置时，应安排客户端统一卸载和重新挂载窗口。长期保持服务端文件系统标识与导出关系稳定。
