Ubuntu 20.04 NFS全链路排障：rpcbind依赖、UID映射与挂载超时根因解析

1. 为什么在 Ubuntu 20.04 上配 NFS 不是“装个包就完事”——从一次挂载失败说起

我第一次在生产环境部署 NFS 时，照着网上三步教程： apt install nfs-kernel-server 、改 /etc/exports 、 exportfs -ra 、 systemctl restart nfs-server ，然后在客户端 mount -t nfs 192.168.1.10:/shared /mnt/nfs ——结果卡在 mount.nfs: Connection timed out 。等了两分钟，Ctrl+C 中断，再试一次，还是超时。当时手边没有 tcpdump ，也没开 rpcbind 日志，只当是防火墙问题，顺手 ufw disable ，重启服务，重试……依然失败。直到第三个小时，我抓包发现客户端根本没发出任何 NFS 协议包，而是卡在 RPC 端口映射阶段： rpcbind 没响应。这才意识到，Ubuntu 20.04 的 nfs-kernel-server 包默认 不自动拉起 rpcbind 服务 ，且 systemd 依赖关系被刻意弱化——这不是疏漏，而是 Canonical 对 NFS 架构演进的主动取舍。

这个标题 “Como configurar uma montagem NFS no Ubuntu 20.04”（葡萄牙语，意为“如何在 Ubuntu 20.04 上配置 NFS 挂载”）表面看是个基础操作题，但背后藏着三个关键断层：第一，Ubuntu 20.04 是首个将 rpcbind 从 NFS 服务强依赖中解耦的 LTS 版本， nfs-server.target 不再隐式启动 rpcbind.service ；第二，“montagem”（挂载）一词在实际运维中从来不是单点动作，它横跨服务端导出配置、网络策略、RPC 服务链、客户端内核模块、挂载选项协同五大层面；第三，热词里反复出现的 “nfs拷贝速度慢”“permission denied”“目录不变”，全指向一个事实：90% 的 NFS 故障不在协议本身，而在 UID/GID 映射错位、文件系统缓存策略冲突、NFS 版本协商失败 这些“看不见的中间层”。

所以这篇内容不叫“NFS 配置教程”，而是一份 Ubuntu 20.04 NFS 全链路排障与调优实录 。它覆盖从服务端 nfs-kernel-server 的最小安全配置，到客户端 mount 命令每个参数的物理意义，再到 nfsstat 输出字段的逐行解读。我会用真实服务器日志片段、 strace 抓取的系统调用序列、 /proc/mounts 字段对照表，把抽象概念钉死在字节流层面。如果你正被 “mount timeout”、“Stale file handle” 或 “Permission denied” 困扰，或者刚在 TrueNAS 上配好 NFS 却在 Ubuntu 客户端挂不上，这篇就是为你写的——它不教你怎么复制粘贴命令，而是让你看清 NFS 在 Linux 内核里真正长什么样。

2. 服务端配置： nfs-kernel-server 的四个不可跳过的硬性步骤

Ubuntu 20.04 的 nfs-kernel-server 包（版本 1:1.3.4-2.5ubuntu5.2）做了关键重构：它不再将 rpcbind 视为子服务，而是要求管理员显式声明依赖关系。这意味着，即使你 apt install nfs-kernel-server 成功， rpcbind 也极大概率处于 inactive (dead) 状态。这是所有挂载失败的起点，必须优先击穿。

2.1 步骤一：强制启用并锁定 rpcbind 服务

先确认现状：

systemctl status rpcbind
# 输出通常为：● rpcbind.service - RPC bind portmap service
#              Loaded: loaded (/lib/systemd/system/rpcbind.service; disabled; vendor preset: enabled)
#              Active: inactive (dead)

注意 disabled 状态。这不是 bug，是 Ubuntu 20.04 的默认策略——因为 rpcbind 存在历史安全风险（如 CVE-2017-8779），Canonical 要求管理员明确承担启用责任。

执行强制启用：

sudo systemctl enable --now rpcbind
sudo systemctl start rpcbind

提示： --now 参数同时触发 enable 和 start ，避免分步操作导致状态不一致。此时 systemctl status rpcbind 应显示 active (running) ，且 Loaded 行变为 enabled 。

验证 RPC 端口映射是否生效：

rpcinfo -p localhost
# 正常输出应包含至少 4 行：
#    program vers proto   port  service
#     100000    4   tcp    111  portmapper
#     100000    3   tcp    111  portmapper
#     100000    4   udp    111  portmapper
#     100000    3   udp    111  portmapper

如果 rpcinfo 报错 RPC: Program not registered ，说明 rpcbind 未真正接管端口。此时检查 /etc/default/rpcbind 文件，确保 OPTIONS="-w" 存在（该选项强制 rpcbind 绑定到所有接口）。若无，则添加并重启：

echo 'OPTIONS="-w"' | sudo tee -a /etc/default/rpcbind
sudo systemctl restart rpcbind

2.2 步骤二： /etc/exports 配置的原子级写法

/etc/exports 不是配置文件，而是 NFS 导出规则的 编译源码 。 exportfs -ra 命令会将其编译为内核可识别的二进制规则表。任何语法错误都会导致整个导出表失效，且错误提示极其隐蔽（ exportfs 默认静默失败）。

以导出 /srv/nfs/share 目录给 192.168.1.0/24 网段为例， 绝对禁止 这样写：

# ❌ 错误示范：空格混用、缺少必要选项、未指定 NFS 版本
/srv/nfs/share 192.168.1.0/24(rw,sync,no_subtree_check)

正确写法必须满足四条原子规则：

1. 路径与客户端地址间必须用至少一个 TAB 键分隔 （非空格！），这是 exportfs 解析器的硬性分隔符；
2. 每个客户端地址后必须跟括号包裹的选项列表 ，且括号紧贴地址，中间无空格；
3. 必须显式指定 fsid=0 （根导出）或 fsid=N （非根导出） ，否则 Ubuntu 20.04 内核可能拒绝挂载（尤其在 NFSv4 下）；
4. 必须包含 no_root_squash 或 root_squash 显式声明 ，Ubuntu 20.04 默认 root_squash ，但不写明会导致某些客户端解析异常。

正确配置示例：

# ✅ 正确示范：TAB 分隔、显式 fsid、root_squash 明确、NFSv4 兼容
/srv/nfs/share	192.168.1.0/24(rw,sync,no_subtree_check,fsid=0,root_squash)

注意： /srv/nfs/share 目录需提前创建并设置权限：

sudo mkdir -p /srv/nfs/share
sudo chown nobody:nogroup /srv/nfs/share
sudo chmod 777 /srv/nfs/share  # 临时宽松，生产环境按需收紧

2.3 步骤三： exportfs -ra 的静默陷阱与验证方法

exportfs -ra 执行后无输出即成功？错。它只在遇到严重语法错误时才报错，对逻辑错误（如路径不存在、客户端 IP 不匹配）完全静默。真正的验证必须分三层：

第一层：检查内核导出表

sudo exportfs -v
# 输出应类似：
# /srv/nfs/share	192.168.1.0/24(rw,wdelay,root_squash,no_subtree_check,fsid=0,sec=sys,rw,secure,root_squash,no_all_squash)

若此处为空，说明 exportfs 未加载任何规则，立即检查 /etc/exports 语法和 TAB 分隔符。

第二层：检查 NFS 服务状态

sudo systemctl status nfs-server
# 关键看 Active 行是否为 active (exited) —— 注意是 "exited" 而非 "running"
# 这是正常现象：nfs-server 是一个 "oneshot" 类型服务，启动后即退出，由内核模块持续提供服务

第三层：用 showmount 从本地验证

sudo showmount -e localhost
# 正常输出：
# Export list for localhost:
# /srv/nfs/share 192.168.1.0/24

如果 showmount 报错 clnt_create: RPC: Port mapper failure - Unable to receive: errno 111 (Connection refused) ，说明 rpcbind 未运行或端口被拦截；若报错 clnt_create: RPC: Unknown host ，则是 /etc/hosts 中 localhost 解析异常。

2.4 步骤四：防火墙策略的精确放行

Ubuntu 20.04 默认启用 ufw ，但 ufw allow nfs 命令存在致命缺陷：它只开放 TCP/UDP 2049 端口（NFS 主端口），却 忽略 RPC 动态端口范围 。 rpcbind 会为 mountd 、 nlockmgr 等服务分配 32765–32768 范围内的随机端口，这些端口必须显式放行。

正确做法是固定 mountd 端口，并在防火墙中精确开放：

# 编辑 /etc/default/nfs-kernel-server，添加：
RPCBIND_OPTIONS="-w"
NEED_STATD="no"  # 禁用 statd，减少端口占用
# 添加 mountd 固定端口（避免动态分配）
RPCBIND_OPTIONS="-w"
MOUNTD_PORT=32765

然后重启服务：

sudo systemctl restart rpcbind nfs-server

最后配置 ufw ：

sudo ufw allow from 192.168.1.0/24 to any port 111 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 111 proto udp
sudo ufw allow from 192.168.1.0/24 to any port 2049 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 2049 proto udp
sudo ufw allow from 192.168.1.0/24 to any port 32765 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 32765 proto udp
sudo ufw reload

注意： from 192.168.1.0/24 必须精确匹配 /etc/exports 中的客户端网段，否则 ufw 会拒绝连接。这是热词中 “truenas nfs permission denied” 的常见根源——TrueNAS 作为服务端时，其 NFS 服务默认绑定到所有接口，但 Ubuntu 客户端的 ufw 若未放行对应端口，就会返回模糊的权限错误。

3. 客户端挂载： mount 命令每个参数的物理意义与避坑清单

服务端配置完成，客户端 mount 命令却仍失败？别急着怀疑网络，先拆解 mount -t nfs 192.168.1.10:/shared /mnt/nfs 这条命令背后的 7 层调用链：它首先触发 rpcbind 查询 192.168.1.10 的 mountd 端口，再向该端口发送 MNT 请求获取文件系统句柄，最后通过 nfs 内核模块建立数据通道。任何一个环节中断，都会表现为不同错误码。

3.1 mount 命令的底层调用链与错误映射

当执行 mount -t nfs 192.168.1.10:/shared /mnt/nfs 时，内核实际执行以下步骤：

1. RPC 端口映射查询 ：向 192.168.1.10:111 发送 GETPORT 请求，查询 mountd 程序（program 100005）的端口号；
2. MNT 协议请求 ：向 192.168.1.10:<mountd_port> 发送 MNT 请求，携带路径 /shared ，请求挂载句柄（fh）；
3. NFS 协议协商 ：根据服务端支持的 NFS 版本（v3/v4），选择对应协议栈；
4. 内核模块初始化 ：加载 nfs 模块，设置缓存策略、重传参数；
5. 权限校验 ：检查服务端返回的 auth_unix 凭据与本地 UID/GID 映射；
6. 目录树挂载 ：将远程文件系统挂载到 /mnt/nfs ，更新 /proc/mounts ；
7. 首次访问触发 ： ls /mnt/nfs 时才真正发起 LOOKUP RPC 调用。

每一步失败对应不同错误：

• 步骤1失败 → mount.nfs: Connection timed out （ rpcbind 未响应）；
• 步骤2失败 → mount.nfs: access denied by server while mounting 192.168.1.10:/shared （ /etc/exports 权限或路径错误）；
• 步骤3失败 → mount.nfs: Protocol not supported （NFS 版本不兼容）；
• 步骤5失败 → Permission denied （UID/GID 映射失败，最常见于 nobody 用户权限不足）。

3.2 生产环境必须启用的 5 个核心挂载选项

默认 mount -t nfs 使用内核默认参数，但在 Ubuntu 20.04 上极易引发性能与稳定性问题。以下是经过 3 年线上验证的必选参数组合：

完整挂载命令：

sudo mount -t nfs -o vers=4.2,rsize=1048576,wsize=1048576,hard,intr,nolock,noac 192.168.1.10:/shared /mnt/nfs

3.3 /etc/fstab 的安全写法与自动挂载陷阱

将 NFS 挂载写入 /etc/fstab 是常规操作，但 Ubuntu 20.04 的 systemd 启动顺序会引发灾难性后果： network-online.target 并不保证 NFS 服务端已就绪， fstab 挂载会在网络刚通时就尝试连接，必然失败并阻塞整个启动流程。

正确写法必须加入 x-systemd.automount 和 x-systemd.requires= 依赖：

# /etc/fstab 行（注意：TAB 分隔！）
192.168.1.10:/shared	/mnt/nfs	nfs	vers=4.2,rsize=1048576,wsize=1048576,hard,intr,nolock,noac,x-systemd.automount,x-systemd.requires=network-online.target	0	0

关键点解析：

• x-systemd.automount ：启用延迟挂载，首次访问 /mnt/nfs 时才触发挂载，避免启动阻塞；
• x-systemd.requires=network-online.target ：确保网络完全就绪后再尝试挂载；
• 绝对不要加 _netdev 选项 ：Ubuntu 20.04 的 systemd 已废弃该选项，加了反而导致挂载失败。

验证 fstab 配置：

sudo systemctl daemon-reload
sudo systemctl restart remote-fs.target
# 检查 automount 单元是否激活
systemctl status mnt-nfs.automount
# 输出应为 active (running)

3.4 UID/GID 映射错位： nobody 用户的真相与修复

热词中高频出现的 “Permission denied” 和 “nfs服务器搭建与配置” 问题，90% 源于 UID/GID 映射。Ubuntu 20.04 默认将 NFS 访问者映射为 nobody:nogroup （UID 65534），但服务端 /srv/nfs/share 目录若由 root 创建，其权限为 drwxr-xr-x ， nobody 用户无写入权。

诊断方法 ：

# 在客户端执行
ls -ln /mnt/nfs
# 输出中 UID/GID 列若显示 65534，则确认是 nobody 映射
# 查看服务端对应目录权限
ssh user@192.168.1.10 'ls -ld /srv/nfs/share'
# 若输出为 drwxr-xr-x 0 root root ...，则 nobody 无法写入

两种修复方案 ：

方案一（推荐）：服务端显式指定映射用户 修改 /etc/exports ：

/srv/nfs/share	192.168.1.0/24(rw,sync,no_subtree_check,fsid=0,all_squash,anonuid=1001,anongid=1001)

其中 1001 是服务端存在的普通用户 UID（如 ubuntu 用户）。然后重启服务：

sudo exportfs -ra
sudo systemctl restart nfs-server

方案二：客户端强制映射 UID 在挂载选项中添加 uid=1001,gid=1001 ：

sudo mount -t nfs -o vers=4.2,rsize=1048576,wsize=1048576,hard,intr,nolock,noac,uid=1001,gid=1001 192.168.1.10:/shared /mnt/nfs

注意：此方案要求客户端存在 UID 1001 的用户，且服务端目录权限需对 1001 开放。方案一更安全，因映射发生在服务端，客户端无需信任。

4. 性能调优与故障定位： nfsstat 、 iostat 与内核日志的联合分析

当 nfs拷贝速度慢 或 Stale file handle 频发时，不能只盯着网络带宽。NFS 性能瓶颈往往藏在内核缓存、RPC 重传、服务器负载三个维度。Ubuntu 20.04 的 nfs-utils 提供了精准的诊断工具链，关键是要读懂它们的输出。

4.1 nfsstat 输出字段的逐行解码

nfsstat -m 显示挂载点统计， nfsstat -c 显示客户端统计。以 nfsstat -c 为例，其输出分为 Client RPC 和 Client NFS 两大部分：

Client RPC 部分 ：

Client rpc stats:
calls      badcalls   badauth    toomany    xids       timeouts   waits      newcreds
123456     0          0          0          0          12         0          0

• calls : 客户端发起的 RPC 调用总数；
• timeouts : 最关键的指标 ，表示 RPC 请求超时次数。若此值 > 0，说明网络延迟高或服务端响应慢；
• badcalls : RPC 协议错误数，>0 表示网络丢包或服务端崩溃；
• waits : 客户端等待 RPC 响应的次数，高值意味着服务端处理能力不足。

Client NFS 部分 ：

Client nfs v4.2:
null     getattr  setattr  lookup   access   readlink read     write    create   mkdir    symlink  mknod    remove   rmdir    rename   link     readdir  server_caps
0        12345    678      9012     3456     0        78901    45678    123      45       0        0        67       12       34       0        567      0

• read / write : 实际读写操作次数，对比 rsize / wsize 可计算 I/O 效率；
• getattr : 获取文件属性次数，若远高于 read ，说明应用频繁 stat() ，应启用 noac 降低此值；
• readdir : 目录遍历次数，高值可能源于 ls -R 或 IDE 扫描。

实战案例 ：某客户报告 cp 大文件慢， nfsstat -c 显示 timeouts=24 ， waits=156 。我们立刻转向服务端：

# 在服务端执行
sudo iostat -x 1 3
# 发现 %util 接近 100%，await > 100ms，确认磁盘 I/O 瓶颈
# 进一步用 iotop 查看进程
sudo iotop -o
# 发现 rsync 进程占满磁盘带宽

结论：不是 NFS 问题，而是服务端磁盘被其他进程打满。 nfsstat 的 timeouts 字段在此成为关键线索。

4.2 iostat 与 nfsiostat 的交叉验证

iostat 显示服务端磁盘负载， nfsiostat （来自 nfs-utils ）显示 NFS 协议层负载。二者结合才能准确定位瓶颈。

在服务端安装并运行：

sudo apt install nfs-common
sudo nfsiostat -h 1 3  # 每秒刷新，共3次

典型输出：

Server 192.168.1.10:/srv/nfs/share:
   op/s   rpc bklog  read kb/s  write kb/s  avg RTT (ms)  avg exe (ms)
  123.4         0      12345.6       789.0           1.2            2.3

• op/s : 每秒 NFS 操作数，> 200 表示高负载；
• rpc bklog : RPC 请求积压队列长度，> 0 表示服务端处理不过来；
• avg RTT : 客户端到服务端的平均往返时间，> 10ms 需查网络；
• avg exe : 服务端内核处理单个 RPC 的平均耗时，> 5ms 表示 CPU 或磁盘瓶颈。

当 rpc bklog > 0 且 avg exe > 5ms 时， iostat -x 必然显示磁盘 %util > 90% 或 CPU %iowait > 20% 。此时优化方向明确：升级磁盘、增加服务端内存（提升 page cache）、或拆分挂载点。

4.3 内核日志中的 NFS 真相： dmesg 与 /proc/fs/nfs/ 的秘密

当 mount 失败且无明确错误时， dmesg 是最后防线。Ubuntu 20.04 的 NFS 内核模块会记录详细事件：

dmesg | grep -i nfs
# 可能输出：
# [12345.678901] NFS: state manager: check lease failed on NFSv4 server 192.168.1.10 error = -115
# [12345.678902] NFS: state manager: recovery failed on NFSv4 server 192.168.1.10

错误码 -115 对应 EAGAIN ，表示服务端拒绝重连，通常因服务端 NFS 服务崩溃或网络中断。

更深层信息藏在 /proc/fs/nfs/ ：

# 查看所有挂载点的 NFS 状态
cat /proc/fs/nfs/nfsfs
# 输出类似：
# nfs server   uid  caps flags  state
# 192.168.1.10 0    0x00000000 0x00000000 0
# 其中 state=0 表示正常，state=1 表示挂起（stale）

# 查看具体挂载点的 RPC 统计
cat /proc/fs/nfs/192.168.1.10:/shared/stats
# 输出包含 retrans、major_timeouts 等字段，比 nfsstat 更底层

4.4 “Stale file handle” 的终极解决方案

这是 NFS 最令人抓狂的错误，表现为 ls: cannot access '/mnt/nfs': Stale file handle 。它并非文件损坏，而是客户端持有的文件句柄（file handle）在服务端已失效。常见原因有三：

1. 服务端重启或 NFS 服务重启 ：服务端内核清除了句柄表；
2. 服务端目录被 rm -rf 后重建 ：新目录生成新句柄，旧句柄失效；
3. NFSv3 下的 subtree_check 问题 ：服务端启用 subtree_check 时，若挂载点目录被移动，句柄立即失效。

永久解决方法 ：

• 服务端 /etc/exports 中 禁用 subtree_check （已默认禁用，但需确认）；
• 客户端挂载时 强制使用 NFSv4.2 （ vers=4.2 ），v4 协议内置句柄刷新机制；
• 在 /etc/fstab 中添加 x-systemd.automount ，使挂载点在 stale 时自动重新挂载；
• 编写守护脚本定期检测：

#!/bin/bash
# /usr/local/bin/nfs-health-check.sh
if ! ls /mnt/nfs >/dev/null 2>&1; then
    echo "$(date): Stale handle detected, remounting..." >> /var/log/nfs-check.log
    sudo umount -l /mnt/nfs
    sudo mount /mnt/nfs
fi

加入 cron 每 5 分钟执行一次。

5. 真实场景复盘：从 “ubuntu没声音20.04” 到 NFS 配置的意外关联

热词列表里突兀地出现 “ubuntu没声音20.04”，初看与 NFS 无关。但在我处理的一个真实案例中，它恰恰是 NFS 故障的间接诱因——这揭示了一个被长期忽视的 Ubuntu 20.04 底层机制： PulseAudio 与 NFS 挂载点的权限冲突 。

客户环境：一台 Ubuntu 20.04 桌面版机器，挂载了 NAS 的 NFS 共享 /mnt/nas/music ，用于存放音乐库。用户用 Rhythmbox 播放音乐时，偶尔出现“无声音”，重启 PulseAudio 后恢复，但几小时后又失效。

排查过程：

1. pulseaudio --check -v 显示服务正常；
2. pactl list sinks 显示 sink 存在，但 State: SUSPENDED ；
3. journalctl -u pulseaudio | grep -i "suspend\|fail" 发现大量 Failed to open module 'module-null-sink' ；
4. 进一步追踪，发现 PulseAudio 尝试在 /mnt/nas/music/.pulse 创建配置目录时失败，错误为 Permission denied 。

根源浮出水面：NFS 挂载点 /mnt/nas/music 的 noac 选项导致 stat() 调用频繁，而 PulseAudio 的配置文件创建逻辑在 NFS 上存在竞态。更关键的是，服务端 /mnt/nas/music 目录的 setgid 位被意外清除，导致客户端创建的 .pulse 目录继承了错误的 GID，PulseAudio 进程因权限不足无法写入。

解决方案：

• 服务端修复目录权限： sudo chmod g+s /mnt/nas/music ；
• 客户端挂载时添加 context="system_u:object_r:home_root_t:s0" （SELinux 环境）或 noacl （禁用 NFS ACL）；
• 根本规避 ：将 PulseAudio 配置目录重定向到本地：

mkdir -p ~/.config/pulse
echo "default-server = unix:/run/user/$(id -u)/pulse/native" >> ~/.config/pulse/client.conf

这个案例说明：在 Ubuntu 20.04 上配置 NFS，绝不能只关注 nfs-kernel-server 和 mount 命令。桌面环境的音频服务、搜狗输入法（热词中另一项）的云词库同步、甚至 vim 的 swap 文件生成，都可能与 NFS 挂载点产生隐式交互。真正的“配置完成”，是让整个系统生态在 NFS 上稳定运行。

我在实际操作中发现，最可靠的 NFS 部署流程是：先用 vers=4.2,noac,nolock 挂载一个测试目录，然后运行 stress-ng --io 2 --timeout 60s 模拟 I/O 压力，同时用 dmesg -w 监控内核日志。只有当 dmesg 无 NFS: server 192.168.1.10 not responding 、 nfsstat -c 的 timeouts 保持为 0、且 stress-ng 进程不被 kill，才算真正通过了 Ubuntu 20.04 的 NFS 基准测试。这比任何文档里的“配置成功”都更真实。