虚拟机配置nfs网络不通怎么办，nfs挂载失败排查方法？

虚拟机NFS网络不通，排查顺序比技巧更重要

虚拟机配置NFS时网络不通，绝大多数情况下是防火墙规则、服务未启动或者exports配置错误造成的，按“先网络层、再服务层、最后配置层”的顺序排查，几分钟内就能定位问题。

为什么虚拟机NFS不通，先分清是“ping不通”还是“挂载不上”

很多人一上来就折腾exports文件，结果发现白忙一场，NFS网络不通在现象上分为两类，处理思路完全不同，第一类是虚拟机之间完全ping不通，这属于网络隔离或IP配置故障；第二类是ping能通，但mount挂载时卡住或报错,这通常是NFS服务本身或防火墙对特定端口做了拦截。

加载中

部署NFS服务-操作过程

一条鲸龙

129720-

原视频地址

判断方法很简单：在客户端执行ping 服务端IP，如果ping百分之百丢包，问题在虚拟网络层面，比如VMware的NAT网段和桥接模式不一致，或者OpenStack安全组没有放行ICMP协议，如果ping正常但挂载超时，重点转向NFS依赖的端口检查NFSv3依赖portmapper（111端口）和mountd（随机端口），NFSv4虽然只用2049端口,但防火墙配置不当同样会卡死。

按这五步走，多数虚拟机NFS网络问题都能自己解决

第一步：先确认服务端NFS服务真的在监听

不少人配置完NFS后从不检查服务状态，在服务端执行systemctl status nfs-server，看到active (running)不代表一切正常，还得看rpcbind是否存活，NFSv3必须依赖rpcbind，它一旦挂掉，客户端挂载时直接报mount.nfs: Connection timed out。

用rpcinfo -p 服务端IP查看输出列表，如果能看到nfs、mountd、portmapper三项，说明RPC注册正常，如果只看到portmapper而看不到nfs和mountd，是NFS服务本身崩溃或配置文件语法错误，此时去查/etc/exports的每一行，路径和权限之间要用空格分隔，网段掩码格式必须是168.1.0/24，写成168.1.会直接导致服务无法启动。

第二步：防火墙是虚拟机NFS不通的头号嫌疑

行业共识是防火墙导致的问题占NFS链接故障的一半以上，尤其是CentOS 7/8、Ubuntu 22.04这些默认开启firewalld或ufw的系统,NFS端口没放行必挂。

先讲最省事的做法：在服务端临时关闭防火墙验证。systemctl stop firewalld（CentOS/RHEL）或ufw disable（Ubuntu），客户端立刻重新mount，如果通了，问题确认是防火墙，然后按最小权限原则放行端口,不建议长期关防火墙。

放行NFS的正确姿势包括两部分，NFSv4只需放行2049/tcp；如果兼容旧客户端用NFSv3，除了2049，还要放行111/tcp和udp、以及mountd的随机端口，mountd端口每次重启可能会变，稳妥做法是在

/etc/nfs.conf的[mountd]段里固定端口，比如port=4001，然后防火墙放行4001/tcp,命令参考：

• firewall-cmd --permanent --add-service=nfs
• firewall-cmd --permanent --add-service=rpc-bind
• firewall-cmd --permanent --add-service=mountd
• firewall-cmd --reload

注意安全组层面的问题，云虚拟机用了安全组的话，安全组规则和虚拟机内部防火墙是两层关卡，只放行虚拟机内部防火墙没用，还要在安全组里同时放行2049、111、4001端口。

第三步：exports配置错误导致的服务端拒绝

不少老手在配置nfs服务端时，exports文件里的选项顺序写错，NFS服务虽然能启动，客户端却始终报Permission denied,重点检查以下几点：

• 共享目录的绝对路径必须正确，/data和/data/在NFS看来是两个不同概念。
• 客户端IP或网段后面不要加多余空格。
• rw、sync、no_root_squash这些选项用逗号分隔,中间不能有空格。
• 修改exports后必须执行exportfs -arv重载配置,或者干脆重启NFS服务。

举一个常见错误案例：写/data 192.168.1.0/24(rw,sync,no_root_squash)，客户端挂载直接成功；写/data 192.168.1.0/24 (rw,sync,no_root_squash)，客户端挂载报错，区别就在于IP和括号之间多了一个空格，这个空格让NFS把168.1.0/24误认为是一个主机名,解析失败导致访问被拒。

第四步：客户端挂载参数要和服务端匹配

服务端一切正常，客户端挂载仍不通的情况也很常见，问题出现在挂载命令本身的参数上，虚拟机客户端执行mount -t nfs 服务端IP:/data /mnt时，系统默认会尝试NFSv4.2，但老内核的NFS客户端和服务端NFSv4支持程度不一致,会自动回退失败。

这种情况指定版本号挂载：

• mount -t nfs4 服务端IP:/data /mnt 强制使用NFSv4。
• mount -t nfs -o vers=3 服务端IP:/data /mnt 强制使用NFSv3。

mount命令的-o选项里加上tcp指定传输协议，规避某些虚拟化环境下UDP丢包严重的问题，在VMware Workstation里，NFS走UDP时网络不通或传输极慢的现象不在少数,改用TCP后问题随即消失。

第五步：查看系统日志定位隐藏的网络层报错

前四步都排查完仍无解时，不要在客户端和服务端之间反复猜测，直接看日志文件，服务端查/var/log/messages或/var/log/syslog，过滤nfs和rpc相关关键字，客户端同样查这两个日志文件，重点看

mount.nfs报错的行，日志里出现RPC: Timed out，说明网络层防火墙封了端口；出现NFS: server not responding，说明服务端对客户端请求无响应,多半是服务端iptables规则拒绝。

虚拟化平台层面的网络策略也可能成为隐藏杀手，比如VMware ESXi里的端口组设置了VLAN隔离，两个虚拟机虽然在同一个网段却分属不同VLAN，NFS流量直接被交换机丢弃，KVM虚拟机使用ovs网桥时存在网桥流量过滤规则的话,客户端发出的NFS请求在宿主机层面就被拦截。

虚拟机NFS网络调优，搞懂这几个场景才算真的会配

VMware里两台虚拟机NFS频繁断连

VMware Workstation默认的NAT模式会为虚拟机分配192.168.x.x网段，虚拟机之间通信要经过虚拟NAT设备，NFS流量较大时会触发NAT连接表超时，现象是挂载成功但拷贝大文件中断，这种情况下把虚拟机网络模式改为桥接模式，或在NAT设置里增大TCP超时时间,问题即可解决。

配置NFS服务端网络不通、客户端来自不同网段

跨网段访问NFS涉及路由问题，比如服务端在192.168.1.0/24，客户端在10.0.0.0/24，中间经过三层交换机，服务端exports配置只能写客户端能到达的路径，客户端要用showmount命令验证能看到共享目录，执行showmount -e 服务端IP，如果输出Export list for下面空白，说明客户端与服务端之间的网络虽然能ping通，但服务端的portmapper无法回包,还是回到了防火墙放行的老问题。

NFS客户端开机自动挂载失败

/etc/fstab里加了NFS挂载项，开机后进入系统发现没挂上，Linux系统启动时网络服务尚未完全就绪是常见诱因，NFS挂载请求发出时服务端网络栈还没准备好，此时在fstab的挂载参数里加上_netdev，告诉系统等网络就绪后再挂载，同时加上bg选项让挂载失败时转到后台重试,虚拟机开机后十几秒内自动恢复连接。

排查虚拟机NFS连接超时问题时，这些坑帮你提前避雷

不要忽略NFS客户端的

timeo和retrans参数，它们影响网络抖动情况下的挂载稳定性，在-o参数里设置timeo=50（十分之一秒为单位，即5秒超时）和retrans=5，NFS请求重试次数增加后，在虚拟化环境中网络偶尔丢包就不会直接中断连接，配合soft参数使用,服务端真正宕机时客户端不会无限期阻塞。

NFS网络问题有时和DNS解析挂钩，服务端主机名解析失败会导致NFS服务启动时注册异常，客户端解析失败则挂载报mount.nfs: mount point /mnt does not exist这种误导性错误，在所有虚拟机的/etc/hosts里写清IP和主机名映射关系,NFS就完全不依赖DNS服务器。

虚拟机NFS没反应？这几个命令组合帮你秒级定位

一条命令串起诊断流程：

• 客户端执行telnet 服务端IP 2049,验证2049端口通不通。
• 服务端执行ss -lntup | grep -E '2049|111|4001',确认NFS相关端口都在监听。
• 客户端执行mount -v -t nfs 服务端IP:/data /mnt,用verbose模式输出详细的挂载过程日志。

看mount的verbose输出，在报错之前会有mount.nfs: Trying text-based options这样的提示行，后面跟的参数列表就是本次挂载的实际配置，如果显示port=0而服务端并未固定mountd端口，挂载时客户端无法确定连接端口，就会表现为网络不通，解决方法是回到服务端固定mountd端口,并立即重启NFS服务。

Q&A：虚拟机NFS挂载不上、连接超时和网络配置问题

虚拟机NFS挂载不上，重启服务端后反而更严重了，是什么原因？

重启NFS服务后mountd端口发生变化，客户端仍在尝试连接旧端口，服务端重启后立即在客户端执行umount -f /mnt强制卸载，再重新挂载，频繁重启NFS服务会加剧此问题,建议固定mountd端口后重启一次。

虚拟机NFS连接超时，但服务端本机访问自己共享目录正常，是什么导致？

服务端本机访问走的是回环接口，绕过了网卡和防火墙的出口规则，客户端网络不通时，检查服务端网卡所在区域的防火墙规则是否对入站NFS流量做了限制，以及虚拟交换机上是否存在ACL策略,本机访问无法反映这些外部网络路径状态。

虚拟机配置nfs服务端网络不同网段时，客户端执行showmount能列出共享目录但mount超时，怎么回事？

showmount只查询portmapper（111端口），mount则需连接mountd和nfsd端口，列出共享目录说明111端口通，mount超时则是mountd或nfsd端口被防火墙拦截，确认服务端mountd固定端口后,在客户端放行2049和mountd端口即可解决。