1. NFS 到底占了哪些端口为什么它老是变1.1 从一个典型的挂载卡死现场说起去年年底帮一个做视频后期的朋友排查问题他们的素材库放在一台内网存储服务器上走 NFS 共享给十几台剪辑工作站。服务器和客户端之间隔了一台硬件防火墙之前一直跑得好好的结果机房里做了一次设备重启之后所有工作站挂载全挂mount命令敲下去就卡住等两三分钟弹一句mount.nfs: Connection timed out。我先在服务器本地跑showmount -e localhost导出列表一切正常再rpcinfo -p localhost服务也在。问题明显出在链路上。在服务器上抓包一看客户端确实能问到 111 端口rpcbind回复说 mountd 在 39217然后客户端就拼命往 39217 发 SYN全被防火墙丢了。原因很简单防火墙只放行了 111、2049 和 20048而这次重启之后 mountd 恰好被分配到了 39217。NFS 这套东西除了nfsd的 2049 和rpcbind的 111 之外其余几个辅助服务的端口都是由 rpcbind 动态分配的每次重启都可能换一个新号码。防火墙如果按固定端口做白名单早晚有一天会踩雷。这就是为什么把 NFS 的端口固定下来这件事在内网、云上、容器里都是绕不过去的一步。不管你用的是 CentOS、Ubuntu 还是各种国产化发行版核心思路都一样只是配置文件的位置和参数名有差别。这篇就把整套流程拆开讲一遍包括端口怎么规划、配置写在哪儿、改完为什么有时候不生效、以及几个我在实际环境里踩过的坑。1.2 NFS 相关组件的端口清单先把账算清楚。一套完整的 NFSv3 服务实际上是一堆 RPC 服务凑在一起干活每个都有自己的程序号program number和端口组件RPC 程序号默认端口端口是否固定作用rpcbindportmapper100000111 tcp/udp固定端口注册与查询所有 RPC 服务的通讯录nfsd1000032049 tcp/udp固定真正的文件读写服务NFSv4 也只用这一个mountdrpc.mountd100005随机需要固定处理挂载请求、返回导出列表rpc.statd100024随机需要固定NSM 状态监控配合锁做崩溃恢复lockdnlockmgr100021随机需要固定文件锁内核模块实现rpc.rquotad100011通常 875视发行版磁盘配额查询用得少sm-notify—随机源端口一般不用管statd 的通知发送工具这里有个特别容易混淆的点NFSv4 和 NFSv3 的端口需求完全不同。NFSv4 把挂载、锁、状态监控全部整合进了 2049 这一个端口理论上防火墙只需要放行 2049/tcpmountd、statd、lockd 统统不需要。但现实里很多场景还在用 v3——老版本的备份软件、一些虚拟化平台的存储对接、部分监控探针甚至某些客户端默认就会协商到 v3。所以在没有把握的前提下把 v3 的那几个端口也固定下来是最稳的做法。补充一句如果你看到 137、139、445 这几个端口那是另一套文件共享协议的东西跟 NFS 没有半毛钱关系别在排查 NFS 问题的时候顺手把它们也一起处理了容易越搞越乱。1.3 端口为什么会随机RPC 的注册机制是怎么回事要理解固定端口的必要性得先知道这些端口是怎么来的。rpcbind老名字叫 portmapper本质上是一个通讯录服务。任何 RPC 服务启动时第一件事就是跑到 rpcbind 那里登记我是 mountd程序号 100005我这次监听在 39217 端口。客户端要挂载的时候先问 rpcbind 要 mountd 的地址拿到端口号再去连。关键在于登记的时候如果没有显式指定端口系统就会从本地可用端口范围里随便挑一个。这个范围通常受/proc/sys/net/ipv4/ip_local_port_range影响默认在 32768 到 60999 之间所以你会看到 mountd 在 3 万到 6 万之间跳来跳去。服务器一重启、服务一重载端口就换了。有人会想那我用端口转发不就行了比如在防火墙上把 39217 映射到某个固定端口。这条路走不通——因为 rpcbind 返回给客户端的端口号是服务自己登记的你在中间做 NAT客户端拿到的还是内网真实的那个数字它就会去连那个数字。除非你把 mountd 返回的端口也一起改掉那还不如直接在服务端固定住省事得多。所以正确的解法只有一个方向让这些 RPC 服务在启动时就明确声明我监听在 XXXX 端口然后 rpcbind 登记的就是这个固定值防火墙按这个值放行一劳永逸。2. 固定端口的规划与方案选型2.1 端口号该怎么选别自己拍脑袋我见过有人随手挑了 20000、30000、40001 这种看起来整齐的端口结果一开服务就被 SELinux 拦下来排查半天。端口号的选择其实是有讲究的最优解是直接沿用主流发行版的默认约定值mountd20048tcp udprpc.statd32765tcp udpoutgoing-port 用32766lockd / nlockmgrtcp 用32803udp 用32769rpc.rquotad875nfsd2049本来就是固定的不用动rpcbind111也不用动为什么推荐这几个数字因为它们不是随便定的第一在 firewalld 的预置服务定义里mountd这个 service 已经把 20048 写进去了rpc-bind写的是 111nfs写的是 2049。你用默认值时直接firewall-cmd --add-servicemountd就完事不用手写端口。第二SELinux 的端口类型策略里20048 默认带mountd_port_t标签32765 一带带rpc_statd_port_t标签。如果你用了别的端口就得额外跑semanage port -a去加标签多一步操作就多一个出错的机会。第三很多运维脚本、监控模板、Ansible role 里都是按这组端口写死的你跟社区保持一致将来换个人接手也不用重新解释一遍。提示如果因为端口冲突必须换值尽量选 1024 以上、不要碰 32768 以下已经被系统大量占用的区间同时记得同步改 firewalld 和 SELinux 的策略否则服务起来了但连不通排查起来更费劲。2.2 不同发行版的配置文件差异这是最容易让人迷糊的地方。同一个rpc.mountd在 CentOS 7 和 Ubuntu 22.04 上配置写到完全不同的文件里。发行版主要配置文件说明RHEL / CentOS / Rocky 7 及以上/etc/nfs.confnfs-utils 1.3.0 之后引入的统一配置按服务分段RHEL / CentOS 6 及更早/etc/sysconfig/nfs老的变量式配置现在仍有部分参数残留在这里Debian / Ubuntu/etc/default/nfs-kernel-server、/etc/default/nfs-common分成服务端和客户端两个文件各类基于 RHEL 的国产发行版通常跟随/etc/nfs.conf但个别版本仍保留/etc/sysconfig/nfs的兼容实现NFS-Ganesha用户态服务ganesha.conf参数名完全不同走的是MNT_Port这种写法特别提醒一下 CentOS 7 这一代它属于新旧混用的过渡期/etc/nfs.conf和/etc/sysconfig/nfs可能同时存在。这时候以/etc/nfs.conf为准因为 nfs-utils 的配置服务会先读它、再去合并/etc/sysconfig/nfs的内容。如果两边写了冲突的值行为会变得很难预测——我建议是只在一处写另一处保持注释状态。2.3 三种思路的取舍改配置、放开整段、还是走新协议在真正动手之前其实有三条路可以选不同场景适合不同的方案。第一条是在服务端固定端口。这是最正统的做法一次性配置长期有效。缺点是 lockd 属于内核模块它的端口参数在模块加载那一刻就定死了改完之后基本躲不掉一次重启。适合服务端数量不多、可以安排停机窗口的场景。第二条是防火墙放开一整段端口比如把 32768-60999 全开。这是最省事的方案加一条规则五秒钟搞定。但我不推荐一方面攻击面大得离谱另一方面很多云平台的安全组根本不允许这么大的端口段而且从合规角度讲一个存储服务开放几万个端口审计那一关就过不去。第三条是直接上 NFSv4。如果你能控制客户端版本v4 只需要 2049/tcp 一个端口防火墙规则能砍掉一大半showmount那套东西也用不上了。这是长期最优解但迁移成本在于老客户端可能不支持/etc/exports的写法要调整v4 有伪根文件系统的概念一些依赖 v3 挂载流程的自动化脚本要重写。所以我的建议是——新项目直接上 v4老环境先老老实实固定端口。3. CentOS / RHEL 系固定端口完整实操3.1 修改 /etc/nfs.conf一次写全家先备份再改。备份这个动作看着像废话但我吃过亏某次改错了一个参数名服务起不来还没备份只能凭记忆往回改折腾了四十分钟。cp /etc/nfs.conf /etc/nfs.conf.bak.$(date %F)然后编辑/etc/nfs.conf把下面几段加进去如果已经存在同名段落改值就行不要重复定义[lockd] port32803 udp-port32769 [mountd] port20048 [statd] port32765 outgoing-port32766这里几个参数的含义需要说清楚不然改完还是懵的[lockd] port对应 TCP 上的 nlockmgr 端口udp-port对应 UDP 的。NFSv3 的锁请求默认走 UDP所以两个都得写。[mountd] port是挂载服务监听的端口客户端执行mount和showmount时用的就是它。[statd] port是本地监听的端口outgoing-port是 statd 在主动通知其他节点时使用的源端口。注意是源端口很多人以为这是目标端口配反了。关于[lockd]这一段还有个坑nfs-utils 会把它转换成内核模块参数传递给 lockd 模块但如果模块已经加载了新参数不会自动生效。所以保险起见我通常还会补一份 modprobe 配置cat /etc/modprobe.d/lockd.conf EOF options lockd nlm_tcpport32803 options lockd nlm_udpport32769 EOF两处的端口值必须保持一致。我见过一次两边写得不一样结果 lockd 用了 modprobe 里的值而 nfs.conf 里写的是另一个rpcinfo -p显示的是 A防火墙放的是 B谁也连不上。3.2 老版本 /etc/sysconfig/nfs 的写法如果你维护的是 CentOS 6 或者某些仍在使用老配置体系的系统那对应的写法是这样的# 打开或添加到 /etc/sysconfig/nfs MOUNTD_PORT20048 STATD_PORT32765 STATD_OUTGOING_PORT32766 LOCKD_TCPPORT32803 LOCKD_UDPPORT32769 RQUOTAD_PORT875注意 CentOS 7 上有一种混合写法RPCMOUNTDOPTS--manage-gids --port 20048。这是通过命令行参数的方式传给 rpc.mountd效果和[mountd] port一样。两种方式同时存在时命令行参数的优先级更高容易造成我明明改了 nfs.conf 怎么没生效的困惑。同一台机器上只保留一种写法这是我反复强调的一点。改完之后让配置生效systemctl restart nfs-config 2/dev/null systemctl restart rpcbind systemctl restart nfs-servernfs-config这个服务在部分系统上存在作用是把 nfs.conf 解析成运行时变量如果系统里没有这个单元报错可以忽略。3.3 验证rpcinfo 才是唯一真相服务重启完第一件事是rpcinfo -prpcinfo -p localhost期望输出大致长这样program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100005 1 udp 20048 mountd 100005 1 tcp 20048 mountd 100021 1 udp 32769 nlockmgr 100021 3 tcp 32803 nlockmgr 100024 1 udp 32765 status 100024 1 tcp 32765 status如果 mountd、nlockmgr、status 这三行的端口还是四位数、五位数乱跳说明配置没生效。按下面的顺序检查配置文件语法有没有写错段落名拼错是最常见的、nfs-config有没有跑、服务是不是真的重启了systemctl status nfs-server看启动时间。再补一条命令交叉验证ss -lntup | grep -E 111|2049|20048|32765|32803|32769rpcinfo是问 rpcbind 要的注册信息ss是直接看内核的监听表。两边对上了才算真的稳。3.4 防火墙与 SELinux 放行端口固定住了接下来是放行。firewalld 环境下firewall-cmd --permanent --add-servicerpc-bind firewall-cmd --permanent --add-servicemountd firewall-cmd --permanent --add-servicenfs firewall-cmd --permanent --add-port32765/tcp firewall-cmd --permanent --add-port32765/udp firewall-cmd --permanent --add-port32766/udp firewall-cmd --permanent --add-port32803/tcp firewall-cmd --permanent --add-port32769/udp firewall-cmd --reload firewall-cmd --list-allrpc-bind、mountd、nfs这三个预置服务分别覆盖了 111、20048、2049剩下 statd 和 lockd 的端口需要手动加。之所以要用--permanent加上--reload是因为直接--add-port只对当前运行时生效重启就没了——这个坑几乎每个人都踩过一次。SELinux 方面如果你用的是推荐的那组端口通常不需要额外操作因为标签已经对上了。但如果你确实换了别的端口检查一下semanage port -l | grep -E mountd|statd|rpc需要新增标签时semanage port -a -t mountd_port_t -p tcp 21048 semanage port -a -t mountd_port_t -p udp 21048 semanage port -m -t rpc_statd_port_t -p tcp 32765 # -m 用于修改已存在的条目跑完记得ausearch -m avc -ts recent看看有没有残留的拒绝日志别等客户端报错才回头查。4. Debian / Ubuntu 系的对应做法4.1 两个配置文件各管一摊Debian 系把服务端和客户端的配置拆开了初次接触会觉得有点绕。服务端配置在/etc/default/nfs-kernel-serverRPCMOUNTDOPTS--manage-gids --port 20048 RPCNFSDCOUNT16注意--manage-gids和--port是同一个字符串里的参数中间用空格分隔别写成逗号也别把引号弄丢。RPCNFSDCOUNT是 nfsd 线程数客户端多的话适当调大一般按每客户端 2 到 4 个线程估算。共享侧statd的配置在/etc/default/nfs-commonNEED_STATDyes STATDOPTS--port 32765 --outgoing-port 32766NEED_STATD必须是yes否则 statd 压根不启动锁相关的功能会静默失效——这个失效很隐蔽因为文件读写看起来完全正常只有多客户端同时写同一个文件时才会出问题。lockd 在 Debian 系里同样走内核模块配置方式和前面一样cat /etc/modprobe.d/lockd.conf EOF options lockd nlm_tcpport32803 options lockd nlm_udpport32769 EOF4.2 重启顺序与生效确认Debian 系的服务名和 RHEL 不一样重启命令是systemctl restart rpcbind systemctl restart nfs-common systemctl restart nfs-kernel-server顺序不能反。nfs-common里包含 statdnfs-kernel-server里的 mountd 依赖 rpcbind 已经起来。如果先重启 nfs-kernel-servermountd 可能注册失败但不报错表现就是rpcinfo -p里看不到 mountd 那一行。验证同样是rpcinfo -p加ss。另外 Debian 系的 rpcbind 在新版本里可能被 systemd socket 激活端口 111 的监听在systemctl status rpcbind.socket里能看到别只看rpcbind.service的状态免得误判成服务没起来。4.3 客户端侧要不要固定端口大多数情况下客户端不用管端口——它作为发起方源端口由内核随机分配目标端口按 rpcbind 返回的结果去连。但有两种场景需要处理第一种是服务端做了严格的源端口白名单。比如存储设备只允许来自 665-1023 这个保留端口段的访问。Linux 客户端默认就使用保留端口resvport行为一般没问题如果被改成了noresvport挂载时加回来即可mount -t nfs -o vers3,resvport 10.0.0.10:/data /mnt/data第二种是客户端也需要对外提供锁服务双向 NFS 或者作为 NFS 服务端同时又挂载别人的共享。这时候客户端自己的 lockd 和 statd 也需要固定配置方法和前面服务端完全一致改的是客户端上的同一批文件。还有一个实用技巧如果服务端已经固定了端口客户端可以在挂载时显式指定绕过 rpcbind 查询环节mount -t nfs -o vers3,port2049,mountport20048 10.0.0.10:/data /mnt/data这在 rpcbind 被防火墙挡住、但 2049 和 20048 放行的环境下特别管用。不过要留意这样写死之后服务端换端口就得同步改所有客户端属于用灵活性换确定性按需选择。5. 常见问题与排查速查5.1 改完配置 rpcinfo 还是随机端口这是最常见的一类反馈。按概率从高到低排第一配置文件写在了错误的位置。CentOS 7 同时存在/etc/nfs.conf和/etc/sysconfig/nfs如果两边都写了但值不同实际生效的是 nfs.conf而你可能一直在改 sysconfig。用systemctl cat nfs-server看看服务单元到底读了哪些文件。第二段落名拼错。[mountd]写成[mount]、[statd]写成[statusd]服务不会报错只是静默忽略这一节。改完用nfs.conf的手册页或者直接跑一次配置解析命令核对一下。第三nfs-config服务没跑起来或者跑了但缓存的运行时文件没更新。在部分系统上这个文件是/run/sysconfig/nfs-utils可以直接cat出来看里面的值对不对。第四服务只 restart 了 mountd没有重载 rpcbind。rpcbind 里可能还留着旧的注册记录systemctl restart rpcbind一下再确认。第五lockd 端口没变。这个前面说过lockd 是内核模块改完必须重启机器或者至少把所有 NFS 挂载卸载干净、停掉 nfs 服务后modprobe -r lockd但模块被占用时会提示 Module is in use多数情况下只能重启。5.2 挂载能成功但 ls 卡住不动这种半通的状态通常指向 statd 或 lockd。表现是mount命令返回成功进目录也能进但只要执行ls、cat或者打开大文件终端就卡死几秒到几分钟后恢复或者直接报 I/O 错误。排查思路先在服务端抓包看客户端有没有向 statd 发起请求如果 SYN 发出去没有回应基本可以确定是 statd 的端口没放行。用rpcinfo -p 服务端IP从客户端执行看能不能拿到完整的端口列表——如果命令行输出卡在这一步说明 111 或者 mountd 有阻塞。临时验证可以用nolock选项绕过锁mount -t nfs -o vers3,nolock 10.0.0.10:/data /mnt/data如果加了nolock就一切正常那问题百分百在锁相关组件上。注意nolock只适合排查用生产环境多客户端并发写的场景下关掉锁数据损坏是迟早的事。5.3 那些看起来像但其实是别的问题的现象有几类现象经常被误判成端口没固定好这里一并说清楚省得白折腾。rpcinfo: cant contact portmapper这是 111 端口不通跟固定端口没关系。检查 rpcbind 是否启动、防火墙是否放行。mount.nfs: access denied by server这是/etc/exports里的客户端网段或权限选项不对属于访问控制问题。挂载成功但写入提示 Permission denied检查no_root_squash、目录权限、以及 SELinux 布尔值nfs_export_all_rw跟端口无关。df 命令长时间无响应可能是rpc.rquotad的查询卡住用mount -o noquota临时验证。同一台客户端挂载多个共享后偶尔卡顿检查 nfsd 线程数是否够用cat /proc/fs/nfsd/threads看看实际值。5.4 问题速查表现象最可能原因快速验证手段重启后客户端全部挂载失败mountd 端口漂移防火墙白名单失效服务端执行rpcinfo -p对比防火墙规则配置改完端口仍随机配置文件写错位置或段落名拼错systemctl cat nfs-server看实际读取路径lockd 端口始终是随机值内核模块已加载新参数未生效重启后再次rpcinfo -p确认挂载成功但读写卡顿statd 或 lockd 端口未放行客户端加nolock挂载对比showmount 无法列出共享mountd 端口被防火墙拦截客户端直接连 20048 测试firewalld 规则重启后丢失用了--add-port没加--permanentfirewall-cmd --list-all对比永久配置SELinux 拒绝导致服务异常自定义端口未增加标签ausearch -m avc -ts recent大量 TIME_WAIT 堆积statd outgoing-port 未固定ss -tan | grep 32766观察6. 几个容易翻车的细节和我自己的处理习惯聊完流程说几个纸面文档上不太会写、但实际维护中一定会碰到的东西。第一件是关于重启窗口的安排。因为 lockd 端口变更必须重启我通常会把 NFS 服务端的端口固定操作安排在一次性完成的批次里先改配置再检查语法确认无误之后再挑一个业务低峰期重启。重启之后第一件事不是看服务状态而是立刻在客户端跑一次完整验证——挂载、列目录、写小文件、多客户端并发写同一个文件、再用showmount -e查导出列表。这五步走完心里才有底。第二件是别在客户端自作聪明地改挂载参数。有些人发现端口连不通就顺手加了port、mountport把端口写死在 mount 命令或者/etc/fstab里。这在服务端确实没有固定端口的情况下是权宜之计但如果服务端已经固定好了客户端还写死一堆参数将来服务端一调整就是全线故障。我的习惯是服务端负责固定客户端保持默认自动发现职责清晰。第三件是关于文档。固定端口这件事做过一次之后一定要把最终的端口分配表写进运维文档同时标注清楚是哪台机器、哪个环境、什么时候改的。我接手过一个环境前同事固定了端口但没留记录新的防火墙策略上线时按默认值放行结果 mountd 用的是自定义的 21048全网挂载失败翻了两个小时才定位到。第四件是容器和虚拟化场景的差异。如果 NFS 服务是跑在容器里的配置文件的挂载方式、hostNetwork 的启用、以及 lockd 这类内核模块的处理都会不一样。容器内通常没有权限操作内核模块lockd 的端口实际上取决于宿主机配置要写在宿主机上。这一点在做容器化存储服务时特别容易忽略表现为容器里rpcinfo -p看着正常但客户端挂载后锁功能异常。第五件是用户态 NFS 服务比如 Ganesha的处理方式不同。它不走 nfs-utils 那套配置端口是在自己的配置文件里写的参数名是MNT_Port、NLM_Port、NFS_Port这一类。如果你遇到的是这种部署形态别去改/etc/nfs.conf改了也不生效直接找 Ganesha 的配置块。最后分享一个我自己常用的小脚本改完配置之后一键核对端口是否符合预期免得靠眼睛一行行看rpcinfo的输出#!/bin/bash EXPECTED( 2049 20048 32765 32803 32769 ) OUTPUT$(rpcinfo -p localhost) FAIL0 for p in ${EXPECTED[]}; do if echo $OUTPUT | grep -qw $p; then echo [OK] port $p registered else echo [FAIL] port $p NOT found FAIL1 fi done exit $FAIL挂在变更流程的验收环节里退出码非 0 就直接判定失败比人工确认可靠得多。这个思路其实可以推广到所有改配置—重启—验证的运维动作上把预期结果写成断言让机器去判断人只负责处理失败的情况。