关键是在客户端用tcpdump -i eth0 -s 0 -w nfs_mount.pcap 'host and (port 111 or port 2049 or port 20048)'抓包，聚焦rpc查询、mount请求、nfs协商三阶段报文，结合wireshark过滤rpc和tcp流定位无响应环节。
直接用 tcpdump 抓 NFS 挂载超时的包，关键不是“抓到多少”，而是“抓对哪一层、在哪一端、带什么过滤条件”。NFS 挂载失败（比如 mount: Operation not permitted 或 server not responding, timed out）本质是 RPC 协商卡在某个环节，而 tcpdump 能帮你定位到底是哪一步断了、谁没回、为什么没回。
先明确抓包位置和时机
必须在客户端上抓包——因为挂载动作由客户端发起，超时也发生在客户端内核；服务端日志只能告诉你“我没收到请求”，而客户端抓包能确认“我发了但没回”还是“我根本没发出去”。
执行挂载前启动抓包，命令建议：
tcpdump -i eth0 -s 0 -w nfs_mount.pcap 'host <server_ip> and (port 111 or port 2049 or port 20048)'</server_ip>-
-s 0确保截全包（NFS RPC 包头信息关键） - 显式过滤 111（rpcbind）、2049（nfs）、20048（常见 mountd 动态端口），避免被其他流量干扰
重点看三类交互报文
NFS v3/v4 挂载分三步走，每步失败对应不同报文特征：
-
RPC 查询阶段（端口 111）：客户端向服务端 111 端口发 RPC 查询请求（如查询
mountd程序号 100005），若无响应或返回PROG_UNAVAIL，说明 rpcbind 没运行、没注册 mountd，或防火墙拦了 UDP 111 - Mount 请求阶段（动态端口，如 20048）：客户端拿到 mountd 端口后，向该端口发 MNT request。若 SYN 发出但无 SYN-ACK，或请求发出后长时间无 reply，说明 mountd 进程未监听、被 SELinux 拦截、或服务端防火墙放行了 2049 但漏了动态端口
-
NFS 协议协商阶段（端口 2049）：挂载成功后首次访问（如
ls）会触发 NFS GETATTR 或 LOOKUP。若此处卡住，可能服务端 exports 权限拒绝、UID/GID 映射失败，或网络中间设备（如某些防火墙）静默丢弃 NFS over TCP 大包
用 wireshark 快速定位失败点
把 nfs_mount.pcap 拖进 Wireshark，按以下顺序筛：
- 过滤
rpc，看 RPC Call 是否有对应 Reply；没有 Reply 的 Call 行高亮标红，就是断点 - 右键某条失败 Call → “Follow → TCP Stream”，看 payload 里有没有
ERR_ACCESS或ERR_PROG_UNAVAIL字样 - 检查 TCP 重传：同一 Seq 号多次出现、间隔约 1 秒（默认 timeo=10），说明网络层丢包或服务端无响应
- 对比客户端和服务端时间戳：若客户端已发 5 次重传，服务端
/var/log/messages却一条 mountd 日志都没有，基本可判定请求没抵达服务端
结合系统命令交叉验证
抓包只是线索，需立刻配合命令确认：
- 服务端执行
rpcinfo -p localhost，确认 100005（mountd）、100003（nfs）是否注册且端口非 0 - 客户端执行
showmount -e <server_ip></server_ip>，若失败，说明 mountd 层已断；若成功但 mount 失败，问题在 NFS 层或权限 - 服务端检查
journalctl -u nfs-server -f，挂载瞬间是否有refused mount request from类日志
