1. 问题现场：当开发板遇上Ubuntu 22.04的NFS

最近在调试一块基于T113或者RK3568这类嵌入式开发板时，我遇到了一个相当典型的网络文件系统（NFS）挂载问题。场景是这样的：我的宿主机升级到了Ubuntu 22.04 LTS，内核版本也跟到了5.15或更高。开发板启动后，通过mount -t nfs命令尝试挂载宿主机共享的目录，命令行却无情地返回了“Connection refused”或者“Protocol not supported”之类的错误。而在之前的Ubuntu 20.04甚至18.04系统上，同样的配置、同样的命令，一切顺畅无比。

这个问题的根源，就藏在Ubuntu 22.04（以及其使用的较新Linux内核）对NFS协议版本支持的“收紧”策略里。简单来说，出于安全考虑，默认情况下，新版的NFS服务器（nfs-kernel-server）不再启用对古老的NFS版本2（NFSv2）协议的支持。而很多嵌入式开发板，特别是那些使用较旧内核或简化版BusyBox根文件系统的，其NFS客户端可能默认只支持或优先尝试使用NFSv2进行挂载。这就导致了协议“握手”失败，开发板自然无法访问宿主机上的共享目录。

如果你也卡在了这一步，别急着回滚系统。解决这个问题的核心思路非常清晰：要么让宿主机（Ubuntu 22.04）的NFS服务重新“开口说”NFSv2这门“老方言”，要么让开发板的客户端学会“说”更新的NFSv3或NFSv4协议。本文将带你走通这两条路，并深入背后的原理和排查细节。

2. 核心症结：NFS协议版本演进与安全取舍

要彻底理解并解决这个问题，我们得先拆解NFS协议和Linux内核的默认行为变化。

2.1 NFSv2为何被“边缘化”？

NFSv2是一个非常古老的协议，定义于上世纪80年代。它存在一些固有的局限性，例如：

• 文件大小限制：最大只支持2GB的文件。
• 性能问题：同步写入、较小的数据包大小（8KB）等设计影响了吞吐量。
• 安全性薄弱：其身份验证和授权机制在现代标准下显得非常脆弱，主要依赖主机IP地址和UNIX用户ID/组ID的映射，容易在复杂的网络环境中出现问题。

随着NFSv3（1995年）和NFSv4（2000年及以后）的推出，这些限制被大幅改进。NFSv3支持大文件、异步写入和更大的数据包；NFSv4则整合了强大的安全框架（如RPCSEC_GSS）、复合操作和状态管理。因此，在服务器端继续默认支持NFSv2，相当于维持了一个已知的安全和性能短板。

2.2 Ubuntu 22.04的默认配置变化

在Ubuntu 22.04中，负责提供NFS服务器核心功能的nfs-kernel-server软件包，其默认配置发生了关键变化。主要的配置文件是/etc/default/nfs-kernel-server和/etc/nfs.conf（取决于具体版本和配置方式）。

在旧版本中，NFS服务启动时可能会默认监听并响应多个NFS版本。而在新版本中，为了提升系统安全基线，NFS服务默认只启用NFSv3和NFSv4。当开发板的客户端发起一个NFSv2协议的挂载请求时，服务器端的rpc.mountd和nfsd服务会直接拒绝，因为它们在默认配置下“听不懂”或者被设置为不处理v2的请求。

我们可以通过一个命令来验证服务器当前支持的协议。在Ubuntu 22.04终端执行：

sudo cat /proc/fs/nfsd/versions

典型的输出可能类似于：

-2 +3 +4 +4.1 +4.2

这里的-2表示不支持NFSv2，而+3,+4等表示支持NFSv3和NFSv4。这就是问题的直接证据。

3. 解决方案一：配置Ubuntu NFS服务器支持v2（推荐给老旧开发板）

如果你的开发板内核或客户端工具链较旧，难以升级其NFS客户端以支持v3/v4，那么最直接的方案就是让Ubuntu服务器“倒退”一步，重新启用对NFSv2的支持。这个方法见效快，但需要你评估内网环境的安全性。

3.1 修改NFS服务器核心配置

我们需要修改NFS服务器的核心配置，告诉它需要加载NFSv2的支持模块。主要涉及两个配置文件，现代Ubuntu更倾向于使用/etc/nfs.conf。

方法A：使用 /etc/nfs.conf (推荐)

1. 使用文本编辑器（如nano或vim）打开配置文件：

   sudo nano /etc/nfs.conf

2. 找到[nfsd]部分。如果不存在，可以在文件末尾添加。
3. 确保或添加以下行：

   [nfsd] vers2=y

   这行配置明确指示nfsd服务启用NFSv2支持。
4. 保存并退出编辑器。

方法B：使用 /etc/default/nfs-kernel-server (传统方法)有些系统或安装方式可能仍依赖此文件。你可以检查并修改它：

sudo nano /etc/default/nfs-kernel-server

寻找以RPCNFSDOPTS开头的行。如果存在，确保其中没有--no-nfs-version 2参数。如果有，请删除这个参数。更积极的做法是显式指定支持的版本，例如：

RPCNFSDOPTS="--nfs-version 2,3,4 --debug"

但请注意，直接修改RPCNFSDOPTS可能与/etc/nfs.conf冲突，现代系统建议优先使用nfs.conf。

3.2 重启NFS服务并验证

修改配置后，必须重启NFS相关服务以使更改生效。

sudo systemctl restart nfs-kernel-server # 或者，在某些配置下，可能需要重启 rpcbind 和 nfs-server # sudo systemctl restart rpcbind nfs-server

重启后，再次检查支持的版本：

sudo cat /proc/fs/nfsd/versions

现在，输出应该变为：

+2 +3 +4 +4.1 +4.2

注意-2变成了+2，表明NFSv2已启用。

3.3 更新导出配置并测试

确保你的共享目录导出配置（通常在/etc/exports中）没有限制协议版本。一个简单的导出配置如下：

/home/yourname/nfs_share *(rw,sync,no_subtree_check,no_root_squash)

这里的*表示对所有IP开放，rw是可读写，sync是同步写入，no_subtree_check和no_root_squash是常用于开发环境的选项，允许root用户保持权限。

应用导出配置：

sudo exportfs -ra

现在，你可以在同一网络下的另一台Linux机器（或你的开发板）上尝试挂载。首先在另一台Linux主机上测试是一个好习惯，可以排除网络和基础服务问题：

# 在另一台测试机上 sudo mount -t nfs -o nfsvers=2 <ubuntu_host_ip>:/home/yourname/nfs_share /mnt/test

如果挂载成功，df -h应该能看到该挂载点，并且可以在/mnt/test下创建、删除文件。

注意：在生产环境或对公网开放的服务器上，强烈不建议启用NFSv2。同时，在/etc/exports中使用具体IP或IP段替代*，并考虑结合防火墙规则限制访问，是基本的安全实践。

4. 解决方案二：升级或配置开发板使用NFSv3/v4（更安全的长期方案）

如果条件允许，让客户端“前进”到更新的协议是更优解。这通常涉及两个方面：内核支持和挂载参数。

4.1 检查开发板内核的NFS客户端支持

首先，你需要确认开发板的内核是否编译了NFSv3或NFSv4客户端的支持。

对于使用Buildroot、Yocto等构建的系统： 你需要检查内核配置。通常可以通过以下命令查看当前内核的配置（如果/proc/config.gz存在）：

zcat /proc/config.gz | grep -i nfs

或者，在构建系统（如Buildroot）的make linux-menuconfig中，确保以下选项被启用：

• CONFIG_NFS_FS=y(NFS客户端支持)
• CONFIG_NFS_V3=y(NFSv3客户端支持)
• CONFIG_NFS_V4=y(NFSv4客户端支持) – 可选但推荐
• 对应的网络和RPC支持，如CONFIG_SUNRPC,CONFIG_LOCKD等。

对于使用BusyBox的简单系统： BusyBox自带的mount命令通常支持NFS，但可能默认行为或支持的版本有限。你需要确保BusyBox在编译时启用了NFS支持（CONFIG_FEATURE_MOUNT_NFS=y）。

4.2 在开发板挂载时指定协议版本

即使内核支持v3/v4，客户端的mount命令也可能默认尝试v2。因此，在挂载命令中显式指定协议版本是关键。

尝试使用NFSv3挂载：

mount -t nfs -o nfsvers=3 <ubuntu_host_ip>:/home/yourname/nfs_share /mnt

或者尝试NFSv4：

mount -t nfs -o nfsvers=4 <ubuntu_host_ip>:/home/yourname/nfs_share /mnt

如果nfsvers参数不被识别，可以尝试旧的vers参数：

mount -t nfs -o vers=3 <ubuntu_host_ip>:/home/yourname/nfs_share /mnt

4.3 处理可能的身份验证问题（NFSv4特有）

NFSv4与v2/v3在身份验证模型上有较大差异。如果你使用NFSv4挂载失败，并出现“Access denied”相关错误，可能需要检查：

1. 用户ID映射：确保开发板上执行挂载操作的用户（通常是root）的UID，与Ubuntu服务器上共享目录的所有者UID相匹配。或者，你在Ubuntu服务器的/etc/exports中使用了all_squash或anonuid/anongid选项来将客户端用户映射为指定的本地用户。
2. 挂载选项：有时需要添加-o sec=sys来使用传统的UNIX安全模式，尽管这不是NFSv4的最佳实践。

   mount -t nfs -o nfsvers=4,sec=sys <host_ip>:/share /mnt

5. 深度排查：当基础方案失效时的诊断工具箱

有时候，即使按照上述步骤操作，问题依然存在。这时就需要进行系统性的排查。以下是一个从底层到上层的诊断流程。

5.1 网络连通性与端口检查

这是所有网络服务问题的第一步。确保开发板能ping通Ubuntu主机，并且防火墙没有阻断关键端口。

在开发板上：

ping <ubuntu_host_ip>

在Ubuntu 22.04上，检查防火墙状态。如果使用ufw：

sudo ufw status

NFS需要一系列RPC端口，它们通常是动态分配的。一个简单（但不够安全）的测试方法是暂时禁用防火墙：

sudo ufw disable

（测试完毕后务必重新启用：sudo ufw enable）。如果禁用防火墙后挂载成功，说明是防火墙规则问题。你需要为NFS开放相关服务：

sudo ufw allow from <dev_board_ip_subnet> to any port nfs # 例如：sudo ufw allow from 192.168.1.0/24 to any port nfs

使用rpcinfo工具可以查看RPC服务注册的端口：

rpcinfo -p <ubuntu_host_ip>

你应该能看到portmapper、mountd、nfs等服务及其对应的端口号。

5.2 服务器端日志分析

Ubuntu的journalctl是查看服务日志的利器。在挂载失败时，立即在Ubuntu服务器上查看NFS相关日志：

sudo journalctl -u nfs-kernel-server --since “1 minute ago” -f

或者更全面地查看所有与NFS、RPC相关的内核及服务日志：

sudo journalctl -xe | grep -i nfs sudo journalctl -xe | grep -i rpc

日志中可能会明确出现“refused mount request from <dev_board_ip> for … (NFSv2 not supported)”或类似的错误信息，这能直接确认问题。

5.3 客户端挂载的详细调试

在开发板的挂载命令中增加-v（verbose）甚至-vvv参数，可以输出详细的调试信息：

mount -v -t nfs -o nfsvers=2 <host_ip>:/share /mnt

输出会显示每一步的RPC调用过程，在哪里失败（例如，mount请求被拒绝，还是nfs请求失败）。

也可以使用strace跟踪mount命令的系统调用（如果开发板有该工具）：

strace mount -t nfs -o nfsvers=2 <host_ip>:/share /mnt 2>&1 | grep -i “connect\|send\|recv”

这有助于判断是在网络连接阶段还是协议协商阶段出错。

5.4 检查RPC服务状态

NFS依赖rpcbind（或portmap）服务。确保Ubuntu上该服务正在运行：

sudo systemctl status rpcbind

如果停止，则启动它：sudo systemctl start rpcbind。

在开发板上，你也可以尝试手动调用RPC来测试：

rpcinfo -p <ubuntu_host_ip>

如果这个命令失败或没有列出mountd和nfs服务，说明基础RPC通信就有问题。

6. 进阶配置与性能调优考虑

在解决了基本的挂载问题后，为了获得更稳定、高效的开发体验，可以考虑以下调整。

6.1 优化NFS挂载参数

在开发板的挂载命令或/etc/fstab中，合适的挂载选项能显著提升体验。以下是一些常用参数：

• hardvssoft：hard是默认值，意味着如果服务器无响应，客户端会无限重试，这对于开发环境是可靠的，避免数据损坏。soft则在超时后返回错误，可能导致数据问题，不推荐用于开发。
• intr：允许用户中断因hard挂载而卡住的进程（如ls）。建议与hard一起使用。
• rsize/wsize：读写缓冲区大小。对于千兆网络，可以尝试设置为8192或16384以提升吞吐量。例如：-o rsize=8192,wsize=8192。
• noatime/nodiratime：禁止记录文件访问时间，可以减少不必要的写操作，提升性能。
• tcpvsudp：显式指定使用TCP协议（-o proto=tcp）。NFSv3/v4默认或推荐使用TCP，因为它更可靠。NFSv2早期多用UDP。

一个综合的挂载选项示例（用于/etc/fstab）：

<host_ip>:/home/yourname/nfs_share /mnt/nfs nfs hard,intr,rsize=8192,wsize=8192,noatime,nodiratime,proto=tcp,nfsvers=3 0 0

6.2 处理文件权限与用户映射

NFS的权限基于用户ID（UID）和组ID（GID）。确保开发板上访问文件的用户（如root，UID=0）与Ubuntu服务器上共享目录的权限相匹配。

• no_root_squash：这是开发环境常用选项（在/etc/exports中设置），它允许客户端的root用户在服务器上也拥有root权限。警告：这有严重安全风险，仅用于受信任的封闭开发网络。
• 用户同步：更安全的方式是在开发板和Ubuntu服务器上创建同名的非root用户，并确保他们的UID和GID一致。这样文件权限管理会更清晰。

6.3 为特定开发板环境定制

不同的开发板生态（如ESP32、STM32、全志、瑞芯微等）可能有细微差别。

• Buildroot/Yocto定制：在构建根文件系统时，除了内核配置，还要检查BusyBox或所使用的mount工具包（如util-linux）的编译选项，确保NFS客户端功能完整。
• 内核启动参数：有些开发板可以通过内核命令行（bootargs）直接指定NFS根文件系统。这里也需要明确协议版本，例如：

  root=/dev/nfs nfsroot=<server_ip>:/path/to/rootfs,nfsvers=3 ip=dhcp

• U-Boot环境变量：在U-Boot中设置网络和NFS挂载参数时，也要注意协议兼容性。

7. 总结与个人实践心得

解决Ubuntu 22.04与老旧开发板之间的NFS挂载问题，本质上是一次协议版本的协商。我的个人经验是，在个人开发或实验室内部网络中，临时启用服务器端的NFSv2支持是最快、最直接的解决方案，尤其是当你面对一堆不同年代、不同内核的开发板时。修改/etc/nfs.conf加上vers2=y，重启服务，十有八九问题就解决了。

但从长远和安全性来看，推动客户端升级到NFSv3是更值得投入的方向。花点时间检查并重新配置开发板的内核与根文件系统，在挂载命令中显式加上nfsvers=3，一劳永逸。NFSv4虽然功能强大，但在简单的嵌入式开发环境中，其额外的复杂性（如状态管理、身份验证）有时会带来新的调试负担，除非有特定需求，否则v3通常是稳定性和复杂度的最佳平衡点。

最后，务必善用日志（journalctl）和调试输出（mount -v）。它们是指向问题根源最准确的罗盘。当遇到奇怪的问题时，先别急着乱改配置，静下心来查看日志，往往能发现那些容易被忽略的错误提示，比如权限问题、防火墙拦截，或者仅仅是某次配置修改后忘记重启服务。