NFS服务器网络环境配置的核心逻辑与实操路径
NFS服务器网络环境配置的核心，是先固定服务端IP并规划好共享网段，再按NFS版本放行对应端口，最后用showmount和mount双向验证，而不是装完软件就直接写/etc/exports。 网络层没打通，后面权限、目录映射配得再细都是白费功夫。
为什么网络配置决定了NFS能不能用
NFS从诞生起就是“信任网络”的协议，早期版本靠/etc/hosts和IP段做访问控制，服务端只认来源IP，不认账号密码，这意味着网络环境一旦配错，客户端连RPC握手都过不去。
业内专家指出,NFS故障里相当一部分并不是权限问题，而是端口没放行、网段写错或者路由不通，很多人在exports里写了168.1.0/24，结果客户端在0.0.0/8里，挂载时一直卡在mount.nfs: access denied，回头排查半天才发现是网络规划没做。
所以配置顺序要反过来：先网络，后共享，再权限。
NFS服务器IP地址与网段怎么规划
静态IP是基本要求
NFS服务端IP必须是静态的,DHCP租约一变，所有客户端的fstab挂载全部失效，配置静态地址的常见路径：
- CentOS/RHEL系：编辑
/etc/sysconfig/network-scripts/ifcfg-ens33，设置BOOTPROTO=static，写入IPADDR、NETMASK、GATEWAY、DNS1 - Ubuntu/Debian系：编辑
/etc/netplan/01-netcfg.yaml，用addresses字段写168.10.20/24，routes字段写默认网关，执行netplan apply
配置完成后用ip addr show和ip route确认地址与路由都生效。
网段划分要跟exports写法对齐
服务端共享目录给哪个网段,网络规划就得覆盖哪个网段，常见做法是把存储服务器放在独立VLAN，比如168.20.0/24，业务服务器在168.10.0/24，中间走三层交换，这时exports里写的是客户端所在网段，不是服务端自己的网段。
一个容易踩的坑：exports里写168.10.0/255.255.255.0和写168.10.0/24效果一样，但写168.10.0/16会把范围放大到168.0.0到168.255.255，安全边界完全变了。网段掩码必须跟实际网络规划一致。
多网卡场景的绑定问题
存储服务器常见双网卡：一张管理网，一张存储网，如果两张网卡都在同一网段，NFS流量可能从错误网卡出去，用ip route查看默认路由指向哪张网卡，必要时在exports里绑定特定地址：
# /etc/exports /data/share 192.168.20.0/24(rw,sync,no_root_squash)
客户端挂载时显式指定服务端存储网IP：mount -t nfs 192.168.20.20:/data/share /mnt/share，不要依赖主机名解析，DNS记录指向管理网IP会导致流量走错路径。
NFS服务防火墙端口怎么开放才不影响挂载
先分清NFSv3和NFSv4的端口差异
这是网络配置里最容易出问题的环节,NFSv3依赖rpcbind做端口映射，服务端每次重启，mountd、statd的随机端口都可能变，防火墙如果只放行2049，客户端showmount -e能通，但mount就是挂不上。
行业共识认为,生产环境优先用NFSv4，NFSv4只使用2049一个端口，不再依赖rpcbind，防火墙规则干净得多。
firewalld实操配置
NFSv4方案：
firewall-cmd --permanent --add-service=nfs firewall-cmd --permanent --add-service=mountd firewall-cmd --reload
NFSv3方案需要固定端口再放行,编辑/etc/sysconfig/nfs：
RQUOTAD_PORT=875
LOCKD_TCPPORT=32803
LOCKD_UDPPORT=32769
MOUNTD_PORT=892
STATD_PORT=662
STATD_OUTGOING_PORT=2020然后放行111/tcp、111/udp、2049/tcp、2049/udp以及上面固定的几个端口，用rpcinfo -p确认所有RPC服务端口已固定，不再出现随机高位端口。
云环境的安全组要单独检查
如果NFS服务器跑在云主机上,除了系统防火墙，安全组规则也要放行对应端口，云厂商安全组默认拒绝入站，只开22和80是常见配置，NFS的2049和111需要手动加规则，源地址填客户端网段，不要开0.0.0/0。
NFS跨网段访问怎么配置才不踩坑
路由可达是前提
跨网段场景,先确认服务端和客户端能互相ping通，不通就查三层交换或云上VPC路由表，看有没有到对端网段的路由条目。traceroute能定位断在哪一跳。
exports写法要跟网段匹配
跨网段时exports里写客户端所在网段：
/data/share 192.168.10.0/24(rw,sync,no_subtree_check)
写完执行exportfs -ra重新加载，用exportfs -v查看当前生效规则，注意no_subtree_check能减少跨目录访问时的检查开销，但会略微降低安全性，内网可信环境可以用。
客户端挂载验证
showmount -e 192.168.20.20 mount -t nfs -o vers=4.1 192.168.20.20:/data/share /mnt/share
showmount能列出共享说明RPC链路通了，mount成功才说明数据通道通了，挂载后用df -h看容量，用touch /mnt/share/testfile测写权限，两步都过，网络配置才算闭环。
NFS网络不通怎么排查：四个高频场景
mount卡住无响应
现象是命令挂起几十秒后报Connection timed out，先ping服务端IP，通的话用telnet 192.168.20.20 2049测端口，端口不通就是防火墙或安全组没放行，端口通但还卡，检查rpcinfo -p 192.168.20.20看RPC服务是否注册。
access denied
exports里网段写错或掩码不对是最常见原因。exportfs -v看实际生效规则，跟客户端ip addr显示的地址比对，另外检查/etc/hosts.allow和/etc/hosts.deny有没有拦截。
挂载成功但读写慢
可能是网卡速率协商到百兆,或者MTU不匹配，用ethtool eth0看协商速率，用ping -s 1472 -M do测MTU，跨VLAN场景MTU不一致会导致分片重传，吞吐明显下降。
重启后挂载失效
客户端fstab里写的是主机名，DNS记录变了；或者服务端IP变了。fstab里建议直接写IP，加_netdev选项确保网络就绪后再挂载：
168.20.20:/data/share /mnt/share nfs defaults,_netdev 0 0NFS网络配置参数速查对比
| 配置项 | NFSv3 | NFSv4 |
|---|---|---|
| 依赖rpcbind | 是 | 否 |
| 核心端口 | 111、2049及多个RPC动态端口 | 仅2049 |
| 防火墙复杂度 | 高，需固定多个端口 | 低，放行单端口即可 |
| 跨网段支持 | 需额外配置 | 原生支持 |
| 推荐场景 | 老旧系统兼容 | 新建环境首选 |
据工信部相关技术规范资料,企业内网存储服务应尽量收敛端口暴露面，NFSv4在这方面的优势比较明显。
收束
NFS网络配置说到底就三件事：地址固定、端口放行、路由可达，把这三步做扎实，再去调exports和权限，故障率会低很多。
NFS服务器网络环境配置常见问题
NFS配置时防火墙要开哪些端口？
NFSv4只开2049/tcp和2049/udp即可，NFSv3需要开111的tcp/udp，并把mountd、statd、lockd端口固定后逐一放行，云主机还要同步配置安全组入站规则。
NFS跨网段挂载失败先查什么？
先ping确认三层可达，再telnet测2049端口，然后showmount -e看RPC链路，三步都通再查exports网段写法和hosts.allow，多数跨网段问题出在防火墙只开了2049没开111，或者exports掩码写大了。
NFS服务端IP变了客户端怎么恢复？
客户端先umount旧挂载点，修改/etc/fstab里的IP为新地址，再mount -a重新挂载，如果umount报device is busy，用fuser -mv /mnt/share找到占用进程后处理，不要强制卸载导致数据丢失。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/795809.html
