来源：刘军军 | 发布日期：2026-05-26

NFS 故障排查 SOP

核心原则： 先网络后服务，先服务端后客户端，先基础后性能。所有操作优先读状态，避免直接写/重启。

NFS 常见故障类型（6 类）

标准化排查 SOP（7 步法）

Step 1：确认现象与影响范围

# 客户端：检查异常挂载点
mount | grep nfs
systemctl status nfs-client.target   # RHEL/CentOS 7+

# 服务端：确认当前导出状态
cat /etc/exports
exportfs -v

生产提示：立即记录故障时间、影响业务、是否近期有变更（重启、内核升级、网络策略调整）。

Step 2：基础网络与端口连通性

# 客户端测试端口（NFSv3 依赖 rpcbind+mountd+nfsd）
ping -c 3 <NFS_SERVER_IP>
telnet <NFS_SERVER_IP> 2049    # nfsd
telnet <NFS_SERVER_IP> 111     # rpcbind

# 服务端检查端口监听
ss -tulnp | grep -E '111|2049|mountd'
rpcinfo -p localhost           # 查看注册的 RPC 服务与版本

若 111/2049 不通 → 检查 firewalld/iptables、云平台安全组、中间防火墙策略。

Step 3：服务端进程与配置检查

systemctl status nfs-server rpcbind nfs-mountd
journalctl -u nfs-server -xe --since "2 hours ago"
dmesg -T | grep -i nfs

# 重载导出表（不中断现有会话）
exportfs -rav

关注：rpcbind 是否崩溃、nfsd 是否卡在启动、日志是否有语法错误。

Step 4：客户端挂载状态与内核日志

# 查看挂载选项与状态
cat /proc/mounts | grep nfs

# 内核级 NFS 错误日志（最关键！）
dmesg -T | grep -E 'nfs|NFS' | tail -50
journalctl -k | grep nfs

# 测试挂载（带详细输出）
mount -t nfs -v -o vers=4.2,tcp,hard,intr,rsize=1048576,wsize=1048576 \
  <SERVER>:/path /mnt

卡死通常伴随 NFS: server <IP> not responding, still trying 或 NFS4: state recovery failed。

Step 5：权限与映射验证

# 服务端：检查导出权限与 root 映射
cat /etc/exports
# 示例：/data 10.0.0.0/24(rw,sync,no_root_squash,fsid=0)

# 客户端：验证实际使用的 UID/GID
ls -n /mnt/upload

# SELinux（若开启）
getsebool nfs_export_all_rw

no_root_squash 慎用；生产推荐 all_squash,anonuid=1000,anongid=1000 统一管理权限。

Step 6：性能与协议诊断

# 客户端 NFS 统计（重传、延迟、吞吐量）
nfsstat -c
nfsiostat 5 3

# 服务端线程与队列
cat /proc/fs/nfsd/threads
nfsstat -s

# 抓包定位（最后手段）
tcpdump -i any port 2049 -w nfs_trace.pcap &

retrans 高 → 网络或服务器负载；read/write 延迟大 → 存储 IOPS 或 rsize/wsize 配置问题。

Step 7：安全恢复与业务验证

# 卡死挂载点安全卸载（优先 lazy，再 force）
umount -l /mnt/upload     # 后台延迟卸载，不阻塞

# 若仍卡住且确认无活跃进程：
umount -f /mnt/upload     # 强制卸载（可能丢数据，需评估）

# 重新挂载并验证
mount -a
touch /mnt/upload/.health && rm /mnt/upload/.health

生产红线：未确认业务无写入前，禁止 umount -f；优先协调业务停机窗口。

典型故障实战解析

案例 1：Stale file handle（句柄过期）

• 现象：ls /mnt 报 Stale file handle，部分文件可读写，部分失败
• 根因：服务端重启/导出路径 inode 变更，客户端缓存的 filehandle 失效
• 排查：dmesg | grep -i stale、exportfs -v | grep <path>
• 解法：服务端保持 fsid= 参数固定（推荐 fsid=0 或 UUID）；客户端执行 umount -l && mount -a
• 建议：关键路径使用 NFSv4（自带状态管理，对句柄过期更健壮）

案例 2：挂载点 df/ls 永久卡死

• 现象：任何命令访问 /mnt 无响应，strace 停在 openat()
• 根因：使用 hard 挂载 + 网络闪断 + 未设 intr，客户端内核无限重传
• 排查：cat /proc/mounts | grep "hard,intr"、dmesg | grep "not responding"
• 解法：临时 umount -l 后重挂；永久修复：挂载参数 hard,intr,timeo=14,retrans=3
• 建议：容器/K8s 场景避免 NFS 作为持久化存储，改用 CSI 驱动的分布式存储

案例 3：写入极慢，nfsstat 显示大量 retrans

• 现象：上传 100MB 耗时 2 分钟，监控无 CPU/内存瓶颈
• 根因：exports 使用 sync + 后端机械盘 IOPS 不足 + 默认 rsize/wsize 过小
• 排查：nfsstat -c | grep -i retrans、iostat -x 2
• 解法：非强一致场景改为 async（需评估断电丢数据风险）；挂载参数 rsize=1048576,wsize=1048576

案例 4：Permission denied 但 exports 配置正确

• 现象：root 可访问，普通用户报错；或跨主机 UID 不一致
• 根因：root_squash 默认开启 + 客户端 root 被映射为 nfsnobody；或 UID 未统一
• 解法：exports 添加 all_squash,anonuid=1000,anongid=1000 → exportfs -rav
• 建议：所有 NFS 客户端使用同一套 LDAP/SSO 账号体系，UID/GID 全局一致

生产环境预防与最佳实践

生产血泪教训： fstab 中务必加 _netdev，否则单用户模式会阻塞启动。定期执行 exportfs -v 比对配置与运行时状态，防人为误改。

排查本质

NFS 故障排查本质是 "网络 → RPC → 内核态挂载 → 用户态权限 → 存储性能" 的分层定位过程。

• 优先通过 dmesg 与 nfsstat 锁定方向，避免盲目重启
• 卡死场景用 umount -l 替代 umount -f，保障数据一致性
• 将"临时修复"沉淀为标准化挂载参数与监控基线
• 评估业务 SLA，适时向分布式存储架构演进

掌握上述 SOP 后，90% 以上 NFS 故障可在 15 分钟内定位并恢复。

关联链接

• linux-nfs-mount-parameters-guide — NFS 挂载参数全解析
• server-performance-four-dimensions — 服务器性能五维排查
• network-troubleshooting-order — 网络排查顺序
• linux-load-high-cpu-low-troubleshooting — Linux Load 高但 CPU 低排查
• linux-server-load-case-study — 服务器负载过高排查