企业官网建设流程全解析

1. 为什么我要认真写一份 NFS 配置说明

NFS 这个协议，说起来历史相当悠久，从 1984 年 Sun 公司搞出来到现在，四十多年过去了，它依然是 Unix/Linux 世界里最主流的文件共享方案之一。我在实际工作中接触过的场景里，从几台机器的小型办公网络，到几十上百台服务器组成的计算集群，NFS 几乎无处不在。但有意思的是，很多人对 NFS 的印象停留在“装个 nfs-utils，改个 exports，mount 一下”这个层面，真遇到权限问题、性能问题、安全审计要求的时候，就开始抓瞎了。

这份说明想做的事情很明确：把 NFS 服务端的配置、客户端的挂载使用，从头到尾讲清楚，并且重点覆盖基于 Kerberos 的安全认证配置。后者是很多企业内网、科研机构、金融行业在合规审计时绕不过去的坎——纯 AUTH_SYS 的 NFS 在安全扫描里基本是一票否决项。如果你只是在家里搭个 NAS 玩玩，前半部分够用了；如果你面对的是有安全基线的生产环境，那 Kerberos 那部分请务必看完。

适合谁看？我大致分了三类：第一类是刚接触 Linux 运维的朋友，需要一份能照着敲、能跑通的完整流程；第二类是有一定经验但没碰过 NFS 安全加固的工程师，想搞清楚 Kerberos 那套东西到底怎么和 NFS 对接；第三类是遇到具体故障来查资料的，可以直接跳到问题排查那一节。全文我会尽量把“为什么这么配”讲透，而不是只给一堆命令让你复制粘贴——因为 NFS 的坑，八成出在你不知道某个参数为什么存在。

先说一下我写这份东西的底气来源：这些年我在不同规模的环境里配过 NFS，踩过的坑包括但不限于 exports 权限写错导致客户端挂载后只读、idmapd 域名不匹配导致所有文件变成 nobody、Kerberos 的 keytab 权限不对导致 rpc.gssd 静默失败、防火墙只开了 2049 忘了开 rpcbind 等等。这些坑我都会在对应章节里点出来，让你少走弯路。

2. NFS 整体架构与方案选型思路

2.1 NFS 到底是怎么工作的

要配好 NFS，先得理解它的架构。NFS 本质上是一个基于 RPC（远程过程调用）的文件系统协议，服务端运行着若干守护进程，客户端通过 RPC 机制向服务端发起文件操作请求。这里有个关键点很多人忽略：NFS 本身不负责用户认证，它依赖底层的 RPC 认证机制，这就引出了 AUTH_SYS 和 RPCSEC_GSS 两条路线。

具体来说，服务端侧涉及几个核心组件。rpc.nfsd是真正处理 NFS 请求的主进程，负责文件操作的执行；rpc.mountd处理客户端的挂载请求，校验 exports 配置；rpcbind（老版本叫 portmap）负责把 RPC 程序号映射到具体端口；rpc.statd和rpc.lockd负责文件锁和状态恢复。这几个进程各司其职，缺一个都可能导致功能异常。

客户端侧相对简单，主要是内核里的 NFS 客户端模块加上rpc.statd等辅助进程。挂载的时候，客户端会先联系服务端的 rpcbind 拿到 mountd 的端口，然后向 mountd 请求挂载，mountd 检查 exports 配置决定是否放行，放行后客户端拿到文件句柄，后续的文件操作就直接和 nfsd 打交道了。

理解这个流程非常重要，因为后面排查问题时，你会清楚地知道卡在哪一环：是 rpcbind 没起来、mountd 拒绝了、还是 nfsd 权限不够。

2.2 认证方案怎么选：AUTH_SYS 还是 Kerberos

这是整个配置里最需要想清楚的一个决策。NFS 支持多种安全 flavor，常见的有三种：

AUTH_SYS 的问题在于，它完全信任客户端声称的 UID。也就是说，客户端上一个 root 用户（UID 0）可以轻易伪装成服务端上的任意用户，读写任何有权限的文件。在可信内网里这不算大问题，但一旦有安全基线要求，这就是硬伤。

Kerberos 方案则通过票据机制解决了身份伪造问题。客户端必须先向 KDC（密钥分发中心）证明自己的身份，拿到服务票据后才能访问 NFS。krb5只做认证，krb5i加了完整性校验防止中间人篡改，krb5p则对全部流量加密。我的建议是：如果环境支持，至少上krb5i；对数据敏感度高的场景（比如涉及个人信息、财务数据），直接上krb5p，性能损失在现代硬件上其实可以接受。

选型时还要考虑一个现实问题：Kerberos 意味着你需要维护一套 KDC，这对小团队来说是不小的运维负担。如果只是内部几台机器共享文件，AUTH_SYS 配合网络层隔离（比如独立 VLAN + 防火墙白名单）也是可以接受的折中。但如果你的环境有合规审计，或者多租户共享存储，那 Kerberos 基本是必选项。

2.3 版本选择：NFSv3 还是 NFSv4

NFS 有 v3 和 v4 两个主流版本，v4 又细分为 v4.0、v4.1、v4.2。这个选择直接影响配置复杂度。

NFSv3 是经典版本，无状态设计，依赖 rpcbind、mountd、statd 等一堆辅助进程，端口分散，防火墙配置麻烦。但它的兼容性极好，老系统、老客户端都能用。

NFSv4 是状态协议，把 mount、锁、ACL 等功能都整合进来了，只需要一个端口 2049（配合 Kerberos 时还需要 KDC 的端口），防火墙配置大大简化。v4.1 引入了会话和并行 NFS（pNFS），v4.2 增加了服务端复制、稀疏文件等特性。

我的实际建议是：新环境一律上 NFSv4.2，除非有老客户端兼容需求。v4 的伪文件系统（pseudo filesystem）设计让 exports 配置更清晰，而且 Kerberos 集成在 v4 里也更自然。本文的配置会以 NFSv4 为主，同时给出 v3 的兼容配置说明，因为现实中不少环境还是混合的。

3. 服务端配置全流程实操

3.1 环境准备与依赖安装

假设我们有两台机器：服务端nfs-server（IP 假设为 192.0.2.10），客户端nfs-client（192.0.2.20）。操作系统以主流企业级 Linux 发行版为例，包管理用dnf，其他发行版对应替换即可。

服务端需要安装的包：

dnf install -y nfs-utils rpcbind

如果是 Kerberos 场景，还需要：

dnf install -y krb5-workstation krb5-server krb5-libs

这里有个细节：nfs-utils在新版本里已经包含了很多以前独立的组件，但rpcbind在某些发行版里是单独打包的，别漏了。另外，如果你要用 NFSv4 且不需要 v3 兼容，理论上可以不装 rpcbind，但实践中我建议装上——很多工具和脚本默认会去找它，缺了会有莫名其妙的报错。

创建共享目录并设置权限：

mkdir -p /srv/nfs/shared chown -R nfsnobody:nfsnobody /srv/nfs/shared chmod 755 /srv/nfs/shared

关于属主，这里有个常见误区。很多人习惯把共享目录设成某个普通用户，但 NFS 的权限映射比较复杂。如果走 AUTH_SYS，客户端的 UID 会直接映射到服务端同名 UID；如果走 Kerberos，则通过 idmapd 做名称映射。为了减少麻烦，共享目录的属主设置要和实际使用场景匹配。我这里用nfsnobody只是示例，实际应该根据你的用户体系来定。

3.2 exports 配置文件详解

/etc/exports是 NFS 服务端的核心配置文件，格式是“共享路径 客户端(选项)”。先看一个基础的 NFSv4 配置：

/srv/nfs/shared 192.0.2.0/24(rw,sync,no_subtree_check,no_root_squash)

逐项解释这些选项，因为每一个都有它的道理：

rw表示读写，对应的是ro只读。这个不用多说，但要注意它控制的是客户端挂载后的默认权限，实际文件操作还受文件系统权限约束。

sync表示同步写入，数据必须落盘后才返回成功。对应的async性能更好但有数据丢失风险。生产环境我强烈建议sync，除非你明确知道自己在做什么。曾经有个案例，某团队为了性能用了async，结果服务端断电后客户端以为写成功的文件全丢了，损失惨重。

no_subtree_check是关闭子树检查。老版本 NFS 会检查请求的文件是否在导出的子树内，这个检查在文件被重命名时容易出问题，而且有性能开销。现代内核里这个检查基本没必要，关掉更省心。

no_root_squash是个敏感选项，它允许客户端的 root 用户保持 root 权限。默认是root_squash，会把客户端 root 映射成nfsnobody。除非你有明确需求（比如客户端需要以 root 身份操作共享目录里的文件），否则不要开no_root_squash，这是安全大忌。

再看 Kerberos 场景的配置：

/srv/nfs/shared 192.0.2.0/24(rw,sync,no_subtree_check,sec=krb5p)

这里用sec=krb5p指定了安全 flavor。注意，一旦指定了 Kerberos，客户端也必须用对应的 flavor 挂载，否则会被拒绝。

还有一个 NFSv4 特有的概念叫伪根（pseudo root）。NFSv4 的 exports 需要有一个根路径，客户端挂载时从根开始。配置方式是在 exports 里加一行：

/srv/nfs *(ro,fsid=0,crossmnt,no_subtree_check) /srv/nfs/shared 192.0.2.0/24(rw,sync,no_subtree_check,sec=krb5p)

fsid=0标记这是 NFSv4 的根。crossmnt允许跨越挂载点。这样客户端挂载server:/就能看到整个伪文件系统树。

改完 exports 后，用exportfs -rav重新加载，-r是重新导出，-a是所有，-v是详细输出。这个命令会打印出实际生效的导出列表，务必看一眼确认没写错。

3.3 服务启动与防火墙配置

启动服务并设置开机自启：

systemctl enable --now rpcbind nfs-server

防火墙配置是 NFS 最容易出问题的地方。NFSv4 相对简单，只需要 2049：

firewall-cmd --permanent --add-service=nfs firewall-cmd --reload

但如果你还要兼容 NFSv3，那就麻烦了，因为 v3 依赖 rpcbind（111 端口）以及 mountd、statd 的动态端口。解决办法是在/etc/nfs.conf里把这些服务的端口固定下来：

[mountd] port=20048 [statd] port=32765 outgoing-port=32766

然后在防火墙放行 111、2049、20048、32765、32766。这也是我推荐新环境直接用 NFSv4 的原因之一——端口管理简单太多。

Kerberos 场景还要确保 KDC 的端口（通常是 88 和 749）可达，不过那是 KDC 侧的配置，这里不展开。

3.4 验证服务端状态

配置完成后，先在服务端本机验证：

showmount -e localhost

这个命令会列出当前导出的共享。如果报错说连不上 mountd，检查 rpcbind 和 nfs-server 是否真的起来了。另一个有用的命令是exportfs -v，它直接读 exports 配置并显示解析后的结果，不依赖网络。

还可以用rpcinfo -p localhost查看所有注册的 RPC 服务，确认 nfs、mountd、statd 都在列表里。这一步在排查客户端挂载失败时特别有用——如果服务端自己都没注册上，客户端肯定连不上。

4. 客户端挂载与使用

4.1 基础挂载操作

客户端安装nfs-utils后，创建挂载点并挂载：

mkdir -p /mnt/shared mount -t nfs4 192.0.2.10:/srv/nfs/shared /mnt/shared

注意 NFSv4 的路径写法。因为有了伪根，挂载路径是相对于伪根的。如果服务端 exports 里/srv/nfs是fsid=0的根，那么客户端应该挂载192.0.2.10:/shared而不是完整路径。这个细节很多人搞混，挂载时报 “No such file or directory” 八成是路径写错了。

挂载成功后用df -h和mount | grep nfs确认。然后做个读写测试：

touch /mnt/shared/test.txt echo "hello nfs" > /mnt/shared/test.txt cat /mnt/shared/test.txt

如果写入报 Permission denied，先别急着改 exports，用id命令看看当前用户的 UID/GID，再对比服务端共享目录的权限。AUTH_SYS 模式下，客户端 UID 直接映射到服务端，UID 对不上就会出问题。

4.2 开机自动挂载的两种方式

临时挂载重启就没了，持久化有两种做法。传统方式是写/etc/fstab：

192.0.2.10:/shared /mnt/shared nfs4 defaults,_netdev 0 0

_netdev很重要，它告诉系统等网络就绪后再挂载，否则开机时可能因为网络没起来而挂载失败，严重时会导致系统启动卡住。

另一种方式是autofs，按需挂载，适合不常用的共享。配置/etc/auto.master加一行/mnt/auto /etc/auto.nfs，然后在/etc/auto.nfs里写shared -fstype=nfs4 192.0.2.10:/shared。autofs 的好处是访问时才挂载，闲置一段时间自动卸载，节省资源。但它的配置相对复杂，排查问题也麻烦一些，小规模场景用 fstab 就够了。

4.3 挂载参数调优

默认挂载参数在大多数场景够用，但有几个参数值得关注：

rsize和wsize控制读写块大小，默认会协商一个较大值（通常 1MB）。如果网络质量差，可以适当调小减少重传。hard和soft决定服务端无响应时的行为，hard会一直重试（可能卡住进程），soft超时后返回错误。我一般用hard配合intr（老内核）或依赖现代内核的中断机制，因为soft可能导致数据损坏。

noatime可以关闭访问时间更新，减少写操作，对性能有正面影响。nodiratime类似，针对目录。这两个在只读为主的场景收益明显。

一个典型的调优挂载命令：

mount -t nfs4 -o rw,hard,noatime,rsize=1048576,wsize=1048576 192.0.2.10:/shared /mnt/shared

5. 基于 Kerberos 的 NFS 安全配置

5.1 Kerberos 基础概念快速扫盲

Kerberos 这套东西初次接触会觉得概念很多，但核心逻辑其实不复杂。它解决的是“如何在不安全的网络上证明你是谁”这个问题。关键角色有三个：客户端（principal）、服务端（也是 principal）、KDC（密钥分发中心，包含 AS 和 TGS 两个服务）。

流程大致是：客户端先向 AS 证明身份（通常用密码或 keytab），拿到 TGT（票据授予票据）；然后用 TGT 向 TGS 申请特定服务的票据；最后拿服务票据去访问 NFS。整个过程票据都是加密的，中间人拿不到也伪造不了。

Principal 的命名格式是primary/instance@REALM，比如nfs/server.example.com@EXAMPLE.COM。NFS 服务端的 principal 通常是nfs/主机名@REALM，客户端用户则是用户名@REALM。

5.2 KDC 侧的准备

假设已经有一套可用的 KDC（搭建 KDC 本身是另一个话题，这里假设它存在，realm 为EXAMPLE.COM）。需要在 KDC 上为 NFS 服务端创建 principal 并导出 keytab：

kadmin.local -q "addprinc -randkey nfs/nfs-server.example.com@EXAMPLE.COM" kadmin.local -q "ktadd -k /etc/krb5.keytab nfs/nfs-server.example.com@EXAMPLE.COM"

把生成的 keytab 安全地传到 NFS 服务端的/etc/krb5.keytab，权限设为 600，属主 root。keytab 里存的是长期密钥，泄露等于身份被盗，权限一定要严。

客户端用户也需要 principal，通常由管理员统一创建。用户登录后通过kinit获取 TGT：

kinit user@EXAMPLE.COM klist

klist能看到当前持有的票据，确认 TGT 存在且未过期。

5.3 服务端 Kerberos 集成配置

服务端需要配置/etc/krb5.conf，指向正确的 KDC：

[libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false [realms] EXAMPLE.COM = { kdc = kdc.example.com admin_server = kdc.example.com } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM

然后配置 idmapd，这是 Kerberos 场景的关键组件。因为 Kerberos 用 principal 标识用户，而文件系统用 UID/GID，idmapd 负责两者之间的映射。编辑/etc/idmapd.conf：

[General] Domain = example.com [Mapping] Nobody-User = nfsnobody Nobody-Group = nfsnobody

Domain必须和 Kerberos realm 对应（通常是小写形式），这个不匹配是 Kerberos NFS 最常见的故障原因——所有文件都显示成 nobody，就是因为映射失败。

启动相关服务：

systemctl enable --now rpc-gssd systemctl restart nfs-server

rpc-gssd是处理 GSSAPI（Kerberos 认证）的守护进程，没有它 Kerberos 认证根本走不通。

5.4 客户端 Kerberos 挂载

客户端同样需要配置krb5.conf和idmapd.conf，然后用户先kinit拿到票据，再用指定 flavor 挂载：

kinit user@EXAMPLE.COM mount -t nfs4 -o sec=krb5p 192.0.2.10:/shared /mnt/shared

挂载后验证：

klist ls -la /mnt/shared

如果ls显示的文件属主是数字 UID 而不是用户名，说明 idmapd 映射有问题，回头检查两端的idmapd.conf域名是否一致。如果挂载直接报 “Permission denied”，检查rpc-gssd是否运行、keytab 是否正确、票据是否有效。

6. 常见问题排查与避坑经验

6.1 挂载失败排查速查表

6.2 几个我踩过的坑

第一个坑是防火墙只开了 2049 但没开 rpcbind。NFSv4 理论上不需要 rpcbind，但某些客户端实现会先尝试联系 rpcbind，如果被防火墙 drop 而不是 reject，会导致挂载超时很久才失败。解决办法是明确 reject 或者干脆放行 111。

第二个坑是no_root_squash的滥用。有次接手一个环境，发现 exports 里全是no_root_squash，问原因说是“不加的话客户端 root 写不了文件”。这其实是权限设计问题，正确做法是调整共享目录的属组和权限，而不是放开 root 映射。后来改成root_squash配合合适的组权限，问题解决，安全性还提升了。

第三个坑是 Kerberos 的时钟同步。Kerberos 对时间敏感，默认允许的时钟偏差是 5 分钟。有次客户端时间漂移了 10 分钟，kinit一直报 “Clock skew too great”，排查了半天才发现是 NTP 没配好。所以 Kerberos 环境里，NTP 同步是硬性前提。

第四个坑是 keytab 权限。rpc-gssd以 root 运行，keytab 权限 600 属主 root 没问题，但如果有人为了“方便”改成 644，密钥就暴露了。更隐蔽的问题是 SELinux，某些发行版上 SELinux 会阻止 rpc-gssd 读取 keytab，需要设置正确的上下文，用ausearch查拒绝日志能定位。

6.3 性能相关的经验

NFS 性能问题往往不在 NFS 本身，而在底层存储和网络。我遇到过写入慢的情况，最后发现是服务端磁盘 IO 饱和，跟 NFS 参数没关系。排查时先用nfsstat看 RPC 统计，再用iostat看磁盘，用sar -n DEV看网络，逐层定位。

rsize/wsize不是越大越好。在万兆网络里大块传输收益明显，但在千兆或无线环境里，过大的块会导致重传成本高。实测下来，千兆环境 256KB 到 512KB 比较均衡。

还有个小技巧：如果共享目录里小文件特别多，noatime的收益会非常显著，因为每次读都会触发一次元数据写。这个在代码仓库、文档库这类场景里效果立竿见影。

7. 一些收尾的实际体会

配 NFS 这件事，命令本身不难，难的是理解每一层在干什么。我见过太多人照着教程敲完命令，一旦出问题就完全不知道从哪查起。所以这份说明里我花了大量篇幅讲“为什么”——为什么选这个 flavor、为什么 idmapd 要配域名、为什么防火墙要开那些端口。这些理解到位了，遇到新问题你也能自己推出来。

Kerberos 那部分确实门槛高一些，但它的价值在于把“信任客户端”变成了“验证客户端”，这在任何有安全要求的环境里都是必须的。如果你现在还在用 AUTH_SYS，不妨评估一下迁移到sec=krb5i的成本，很多时候没有想象中那么高。

最后分享一个我个人的习惯：每次配完 NFS，我都会在客户端做一轮完整的读写测试，包括创建、修改、删除、重命名、改权限，然后重启一次确认自动挂载正常。这套流程走下来，基本能覆盖 90% 的配置问题。剩下的 10%，就靠日志和nfsstat慢慢磨了。