先按层定位再动手
NFS 挂载是一条链：客户端能到服务端、服务端确实导出了这个路径、双方协商到同一个协议版本且所需端口通、客户端的挂载身份被导出选项放行。链上任何一环断了都表现为「挂不上」，但报错不同。先读报错，再按层验证，可以避免在正确的层上做无效改动，例如服务端根本没导出却一直在客户端调 rsize。
基本信息
| 适用平台 | Linux NFSv3/v4 客户端与服务端 |
|---|---|
| 常用命令 | showmount -e、rpcinfo -p、exportfs -v、mount -v、nfsstat |
| v4 端口 | 仅 2049/TCP |
| v3 端口 | 2049 加 rpcbind(111) 与 mountd 的动态端口 |
| 日志位置 | 服务端 /var/log/messages 或 journalctl；客户端 dmesg 与 syslog |
报错原文与指向
| 报错 | 最常见原因 | 下一步怎么查 |
|---|---|---|
| Connection refused | 服务端 nfs 服务未运行或端口未监听 | 服务端 systemctl status nfs-server，另一端 nc -vz 2049 |
| No route to host | 防火墙丢弃或网络不可达 | 检查主机防火墙与安全组是否放行 2049 及 v3 相关端口 |
| access denied by server | 导出未覆盖该客户端或 sec 模式不匹配 | 服务端 exportfs -v 核对网段与 sec 参数 |
| Protocol not supported | 版本协商失败 | 客户端显式指定 vers=4.2 或 vers=3 重试 |
| Stale file handle | 服务端导出重建或后端存储变化 | 重新挂载或清理客户端句柄缓存后复现 |
| 挂载成功但读写 Permission denied | 不是挂载问题，是 UID/权限位 | ls -ln 看属主，核对服务端目录权限 |
分层排查命令
分层排查命令
ping -c 3 10.0.0.10 # 第一层：网络可达
nc -vz 10.0.0.10 2049 # v4 只需这一个端口
rpcinfo -p 10.0.0.10 # v3 场景确认 rpcbind 与 mountd
showmount -e 10.0.0.10 # 服务端宣告了哪些导出
mount -v -t nfs -o vers=4.2 10.0.0.10:/data/pub /mnt/pub # 显式版本，拿到详细过程客户端侧细节
客户端侧细节
dmesg | tail -n 30 # 内核报错原文常比 mount 输出更有信息量
cat /proc/mounts | grep nfs # 确认已挂载项与实际协商参数
nfsstat -m # 查看版本、rsize/wsize、sec 等生效值
umount -f /mnt/pub # 卡死时强制卸载再重试
mount | grep -c nfs # 确认没有残留的重复挂载NFSv4 不需要 rpcbind，所以「111 端口不通」并不能解释 v4 挂载失败；反过来，强行让老客户端用 v3 时，如果没放行 mountd 的动态端口，就会卡在连接阶段。固定版本是缩小排查面的有效手段。
服务端重建导出目录、更换后端存储或改动导出路径后，客户端上的挂载点可能保留旧句柄，表现为能进入目录但一读文件就报 Stale file handle。此时不要在原挂载点上反复读写，先卸载再重新挂载，避免应用把错误当成数据损坏。
容易被当成挂载故障的两种情况
第一种是权限问题：挂载成功、目录能进，但写入失败，这属于 UID 与权限位范畴，与挂载参数无关。第二种是挂载顺序与开机时序：网络未就绪时自动挂载失败，之后一直没人重试，看起来像服务端不可用。后者在客户端表现为 mount 记录缺失，可通过挂载选项的重试行为或系统挂载单元的顺序调整来解决。