接手一个内部共享存储迁移的活儿，我差点儿被 NFS 的 ro 和 rw 参数优先级问题绊个跟头。当时测试脚本里写了mount -t nfs4 -o ro,rw server:/data /mnt/data，挂载是成功了，文件也看得到，但一执行写入就报只读文件系统；后来我把 ro 去掉只留 rw，写入又恢复正常。同一个命令，只是选项排列方式不同，结果天差地别，这让我意识到——NFS 挂载参数虽然看着简单，但重复选项合并时到底谁赢，真不是靠感觉能猜对的。
这篇文章就把我做的对照实验、踩过的坑和结论完整整理出来。搞清楚 ro 和 rw 的优先级，不只是为了满足好奇心，实际工作里 fstab、systemd 挂载单元、运维脚本三个入口经常互相叠参数，稍不留神就会出现“挂载成功但权限不对”的事故。文章适合正在给服务器配 NFS 共享、被只读写不进去折磨的运维和开发同学，也适合想系统理解 Linux 挂载选项合并机制的人。
1. 一个看似简单、实际容易翻车的参数问题
1.1 事故现场还原
先还原一下当时的情况。我需要在一批 Ubuntu 24.04 节点上挂载一台 NFS 服务器的数据目录，最开始图省事，把挂载参数一股脑写在一条命令里：
mount -t nfs4 -o ro,rw 192.168.122.10:/srv/exports/data /mnt/data挂载命令执行成功，/mnt/data下面的文件也能正常ls，我心想这就算成了。结果后续脚本往目录里写文件的时候，报错信息非常直白：
touch: cannot touch '/mnt/data/aaa.txt': Read-only file system这就很奇怪了。我明明写了rw，为什么最终还是只读？为了定位，我又试了另外一条命令，把顺序对调了一下：
mount -t nfs4 -o rw,ro 192.168.122.10:/srv/exports/data /mnt/data这次挂载完之后，findmnt显示的状态是ro。好，到这里基本能看出规律了：选项列表里靠后的那一个，把头一个覆盖掉了。
这类问题在实际运维里非常隐蔽。很多人写脚本时随手复制以前的命令，再加上ro又加上rw，觉得“反正有个能用的就行”，结果最后生效的不是你以为的那个。更麻烦的是，它不会挂载失败，只是权限表现和你预期不符，属于“静默翻车”。
1.2 为什么这个优先级值得我们仔细研究
有人可能会说，既然最后一个选项说了算，那我写的时候小心一点不就行了？实际上没这么简单。NFS 的挂载选项来源不止一个：
- 手动执行
mount命令时写的-o参数； /etc/fstab里配置的挂载选项；- systemd 的
.mount单元文件里的Options=字段； - 某些自动化部署工具（Ansible、SaltStack、Cloud-init 等）生成的挂载配置。
这些入口经常叠加。比如 fstab 里已经写了ro，运维发现需要临时写数据，没有改 fstab，而是直接执行mount -o rw /mnt/data，这时候到底哪个生效？又比如 systemd 单元文件里写的是Options=ro，但系统里又配置了云初始化脚本，两个参数冲突时谁覆盖谁？
这些场景不搞清楚，排查一次至少折腾半小时。
1.3 三类最容易踩坑的典型场景
我把日常工作中最容易踩坑的情况整理了一下：
| 场景 | 典型写法 | 风险点 |
|---|---|---|
| 命令行重复选项 | mount -o ro,rw ... | 最后一个选项覆盖前面的，写反了就是只读 |
| fstab + 命令行叠加 | fstab 写ro，再执行mount -o rw | 命令行选项追加到 fstab 选项后，优先级更高 |
| systemd 单元 + 默认参数 | Options=ro,nofail | 参数合并后行为依赖 mount 逻辑，不直观 |
文章后面每一类我都会做实验验证。
2. 先理解 NFS 挂载选项的合并与生效逻辑
2.1 ro 和 rw 到底在控制什么
先回到最基础的定义。NFS 挂载选项里的ro表示只读（read-only），rw表示读写（read-write）。这个选项是在客户端发起挂载请求时，传给 NFS 协议栈的“访问模式开关”。
客户端以ro挂载共享目录后，内核 VFS 层会对该挂载点做写限制。即使你当前用户有权限，open()系统调用里带写标志也会被直接拒绝。以rw挂载后，内核允许发起写请求，但最终能不能写成功，还要看 NFS 服务端 export 的权限。这一点第 3.5 节会展开讲。
严格说起来，NFS 的访问控制是双层结构：服务端/etc/exports里的ro/rw是第一层，客户端挂载参数里的ro/rw是第二层。最终生效的权限是两层限制的交集。比如服务端 export 为ro，客户端怎么挂都是只读；服务端 export 为rw，客户端却可以自己选择以ro还是rw挂载。
理解了这层结构，就能明白为什么客户端挂载参数里的优先级很重要——它决定了客户端这边放开到哪一档。
2.2 选项合并的基本逻辑：谁最后出场，谁说了算
Linux 挂载选项的合并机制，核心概念是**“按顺序应用、同类型覆盖”**。mount命令收到-o ro,rw后，会把ro和rw拆成两个选项，逐个配置到挂载请求里。ro先把读写开关设为只读，随后rw又把开关设为读写，所以最终结果是rw。
这就好比一个开关变量被连续赋值两次：
access_mode = ro access_mode = rw # 覆盖前面的值最后读到的自然是rw。
在 util-linux 的mount实现里，包括ro、rw、suid、nosuid、dev、nodev、exec、noexec、async、sync这类互斥选项，基本都是这个处理逻辑：后出现的设置覆盖先出现的设置。
那么defaults选项又是怎么回事？defaults本身不是一个真实的内核选项，它代表一组默认值，其中就包含rw、suid、dev、exec、auto、nouser、async。如果你写的是：
mount -o defaults,ro ...那等价于先应用了rw，再应用ro，最终就是ro。反过来说：
mount -o ro,defaults ...defaults里的rw就会把前面的ro覆盖掉，最终是rw。这个细节很多人不知道，也是 fstab 里“明明写了 ro 却是 rw”的常见原因之一。
2.3 不同配置入口的参数叠加方式
在实际工作里，很少只有一个配置来源。我把三种最常见的入口拆开讲。
命令行入口
mount -o后面的逗号分隔列表内部按从左到右的顺序依次应用。你需要确保互斥选项只有一个，或者你明确知道最后一个才是目标结果。
fstab 入口
/etc/fstab第四列就是挂载选项列表，解析顺序同样是“从左到右依次应用”。比如：
192.168.122.10:/srv/exports/data /mnt/data nfs4 ro,rw,nofail 0 0最终生效的是rw。但生产配置里一般不会这么写，没人故意把ro和rw同时写进 fstab。真正的坑是下面这种：fstab 里写ro，运维图省事直接执行mount -o rw /mnt/data。此时mount命令会先读取 fstab 中这一行的选项，再把命令行里给的选项追加到后面，最后的合并结果是ro,rw，生效的是rw。
这就是为什么在 fstab 配置为ro的情况下，命令行用-o rw能“临时救急”成功——命令行参数追加在后面，把 fstab 的只读覆盖了。但要注意，这个临时覆盖不会写回 fstab，系统重启后挂载依旧是只读。
systemd mount 单元入口
在现代 Linux 发行版里，fstab 会被 systemd 转换成.mount单元处理。你也可以直接写单元文件：
[Mount] What=192.168.122.10:/srv/exports/data Where=/mnt/data Type=nfs4 Options=ro,nofailsystemd 会读取Options=字段拼接挂载参数。它的合并行为和 mount 命令基本一致，但我不建议在单元文件里写Options=ro,rw这种互相冲突的选项。原因很简单：systemd 解析和执行挂载时中间还有一层，依赖“后写覆盖前写”的规则虽然通常有效，但可读性太差。改配置的人很容易看错，以为是ro生效，结果实际是rw。
3. 实操验证：在 Ubuntu 24.04 下实测 ro 与 rw 的优先级
3.1 搭建一个最小化 NFS 测试环境
理论说完了，上实验。我用的环境是两台 Ubuntu 24.04 虚拟机：
- NFS 服务端：
192.168.122.10 - NFS 客户端：
192.168.122.20
服务端安装 NFS 内核服务：
sudo apt update sudo apt install -y nfs-kernel-server创建一个测试导出目录：
sudo mkdir -p /srv/exports/data echo "hello nfs" | sudo tee /srv/exports/data/hello.txt编辑/etc/exports，允许客户端所在网段以rw方式访问：
/srv/exports/data 192.168.122.0/24(rw,sync,no_subtree_check,no_root_squash)重载导出配置：
sudo exportfs -ra sudo systemctl restart nfs-kernel-server客户端安装 NFS 客户端工具：
sudo apt update sudo apt install -y nfs-common创建一个挂载点：
sudo mkdir -p /mnt/data环境准备好了。
3.2 命令行场景实测：顺序决定最终结果
先在客户端执行：
sudo mount -t nfs4 -o ro,rw 192.168.122.10:/srv/exports/data /mnt/data挂载完成后查看实际挂载选项：
findmnt -n /mnt/data -o OPTIONS输出里包含rw，说明生效的是读写。再验证一下写入：
echo "test" | sudo tee /mnt/data/test_from_rw.txt文件成功写入，和预期一致。
接着卸载，把顺序反过来：
sudo umount /mnt/data sudo mount -t nfs4 -o rw,ro 192.168.122.10:/srv/exports/data /mnt/data findmnt -n /mnt/data -o OPTIONS这次输出里包含ro。再执行写入：
sudo touch /mnt/data/test_from_ro.txt直接报错：
touch: cannot touch '/mnt/data/test_from_ro.txt': Read-only file system实验结论很清晰：在命令行里，互斥选项按从左到右顺序应用，后出现的覆盖先出现的。
提示：验证挂载选项最靠谱的命令是
findmnt -n /mnt/data -o OPTIONS，或者直接看/proc/mounts。不要只看mount命令的原始输出，因为它可能包含冗余参数，不够直接。
3.3 fstab 与命令行混用：命令行追加在后、胜出在前
现在测试 fstab 和命令行叠加的情况。先把 fstab 配成只读：
192.168.122.10:/srv/exports/data /mnt/data nfs4 ro,nofail 0 0执行：
sudo systemctl daemon-reload sudo mount /mnt/data findmnt -n /mnt/data -o OPTIONS输出是ro,nofail相关选项，只读生效。这说明 fstab 内部无冲突时，ro按预期工作。
卸载之后，改用命令行加rw：
sudo umount /mnt/data sudo mount -o rw /mnt/data findmnt -n /mnt/data -o OPTIONS这次输出里变为了rw。为什么？因为mount识别到挂载点已经在 fstab 里，它会先读取 fstab 中那行的选项ro,nofail，再把命令行里的rw追加进去，最终组合为ro,nofail,rw。rw在最后，覆盖了前面的ro。
如果命令行写的是-o rw,ro，那最终就是ro，因为ro排在了最后。实际运维中，很多人写的临时命令是mount -o remount,rw /mnt/data，这里remount是动作，rw是模式，逻辑同样成立。
3.4 systemd 挂载单元场景：明确比顺序更重要
再试一下直接写 systemd.mount单元。创建一个文件/etc/systemd/system/mnt-data.mount：
[Unit] Description=Mount NFS data [Mount] What=192.168.122.10:/srv/exports/data Where=/mnt/data Type=nfs4 Options=rw,nofail启动并查看：
sudo systemctl daemon-reload sudo systemctl start mnt-data.mount findmnt -n /mnt/data -o OPTIONS结果是rw，和单元配置一致。
如果单元文件里写Options=ro,nofail，那结果自然就是ro。真正的麻烦在于，有些自动化工具会在 systemd 单元之外再叠加命令行参数，或者通过systemctl edit生成 drop-in 配置。drop-in 中的Options=会和原有参数合并，合并顺序和字段拼接顺序相关，很难一眼判断最终结果。
我的实际建议是：systemd 单元文件里永远不要写互相冲突的选项。与其记得“后写覆盖先写”，不如直接让配置里只有一个答案。系统的可维护性来自于确定性，而不是来自于“大家约定俗成都知道规则”。
3.5 服务端 export 的最终裁决权：客户端 rw 也救不了服务端 ro
最后做一组最容易迷惑人的实验。把服务端/etc/exports改成只读导出：
/srv/exports/data 192.168.122.0/24(ro,sync,no_subtree_check,no_root_squash)重新加载导出配置：
sudo exportfs -ra此时客户端执行：
sudo mount -t nfs4 -o rw 192.168.122.10:/srv/exports/data /mnt/data findmnt -n /mnt/data -o OPTIONS注意，findmnt输出里可能仍然会显示rw，看起来很像是读写挂载。但一旦尝试写入：
sudo touch /mnt/data/write_test.txt你会得到：
touch: cannot touch '/mnt/data/write_test.txt': Read-only file system这组实验说明了一个很多人忽略的事实：服务端 export 的 ro/rw，优先级高于客户端挂载参数。客户端里的rw只是“允许发起写请求”，但服务端有权拒绝处理。只要服务端导出为ro，客户端不管怎么折腾都写不进去。
反过来，如果服务端 export 是rw，客户端可以用ro挂载来自我限制，但这只对本机有效，其他客户端是不会被这个ro约束的。真正想让某个共享绝对只读，必须在服务端/etc/exports里配置ro，而不是指望每个人都自觉用ro挂载。
4. 常见误区与排查技巧
4.1 为什么 mount 显示和你预期不一致
排查这类问题，第一个误区是只信mount命令的输出。mount默认打印的信息经过整理，可能省略了一些参数，也可能保留了旧选项。可靠的方式是以下两种：
# 方式一：findmnt findmnt -n /mnt/data -o TARGET,SOURCE,FSTYPE,OPTIONS # 方式二：直接查看内核记录 cat /proc/mounts | grep /mnt/data/proc/mounts是内核维护的当前挂载参数快照，准确性最高。看到这一行里的模式选项，基本就是最终生效结果。
另外，很多人在测试时忽略了一个细节：同一个挂载点在不同时间可能被重新挂载过。比如 fstab 里配置的是ro，你手动执行mount -o rw,remount /mnt/data后，内核状态变成rw，但 fstab 文件没变。等下一次系统重启或服务重启，又会变回ro。如果你只看当前状态，就会误以为配置没生效。
4.2 rw 不等于真的能写：服务端限制容易被忽略
我见过太多人排查了半天，最终发现客户端参数没问题，是服务端目录权限或 export 选项不对。
除了第 3.5 节讲的服务端ro限制，还有两个常见因素：
- NFS 服务端的
root_squash：客户端的 root 用户会被映射成nobody，而nobody对导出的目录没有写权限时，写入就会失败； - 目录本身的 POSIX 权限：即使 NFS 层面允许写，服务端文件系统上目录的
755权限也会挡掉非属主用户的写入。
排查的时候先跑一遍：
showmount -e 192.168.122.10确认服务端导出的权限到底是什么。再在服务端看导出目录的权限：
ls -ld /srv/exports/data如果服务端目录是 root 所有且权限为 755，而客户端是以 root 挂载但被root_squash映射成nobody，那写入失败就非常合理。
4.3 常见问题速查表
我把实际工作中高频出现的问题汇总成一张表：
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 挂载参数里写了 rw，实际只读 | 同一选项列表中靠后的 ro 覆盖了 rw | findmnt -n /mnt/data -o OPTIONS查看最终值 |
| fstab 写了 ro，临时用 rw 挂载却是只读 | 命令行选项和 fstab 选项顺序叠加后 ro 在后 | 检查命令行-o的顺序，必要时卸载重挂 |
| 服务端导出 rw，客户端挂载 rw 但无法写 | 服务端目录权限 / root_squash | 检查导出目录属主与权限，查看exportfs -v |
| 服务端导出 ro，客户端挂载 rw 但无法写 | 服务端 export 优先级高于客户端 | 这属于正常限制，只能在服务端放开 |
| systemd 单元里写了 ro，实际挂载后是 rw | drop-in 配置叠加了 rw 选项，且排位在后 | systemctl cat mnt-data.mount查看完整合并配置 |
排查的时候，我习惯按“服务端 → 客户端 → 中间网络”三步走：先确认/etc/exports，再确认客户端最终挂载选项，最后看服务端目录权限。这套流程能覆盖绝大部分问题。
5. 我总结的一套实用规则
把这几天实验和过去实际运维的经验放到一起，我给自己定了几条硬规矩。
第一，所有 NFS 挂载配置里，同一个挂载点的互斥选项只保留一个，永远不要同时写 ro 和 rw。这么做不是为了显得干净，而是从根上消除“优先级判断”带来的心智负担。配置的确定性比所谓的灵活性重要得多。
第二，当需要临时调整 rw/ro 时，明确使用 remount 而不是重新整理整条选项列表。比如 fstab 里是ro，临时要写入数据，执行mount -o remount,rw /mnt/data，用完再mount -o remount,ro /mnt/data。remount的动作语义清晰，也比卸载再挂载更稳，不容易影响正在使用文件的进程。
第三，真正需要保障只读的共享目录，必须在服务端/etc/exports里写ro。客户端挂ro只是自我保护，防不住其他客户端乱写。对数据安全要求高的场景，服务端出口把权限关死，剩下的事才好控制。
我在实际使用中发现，NFS 的 ro/rw 并没有想象中那么玄乎，它就是一套普通 Linux 挂载选项机制叠加 NFS 特有的双层权限模型。只要记住三条关键结论：客户端命令行里后写的覆盖先写的；命令行叠加 fstab 时，命令行追加在后面所以优先级更高；服务端 export 的 ro/rw 是最终裁决，客户端参数无法越过。这三条能想明白，绝大多数挂载权限问题都能一眼定位。
最后再分享一个小技巧。排查 NFS 权限问题时，别急着反复卸载挂载。先同时打开两个终端，一个看/proc/mounts的实时变化，一个在服务端跑exportfs -v确认导出权限，再在客户端尝试写入。三个维度的信息对齐之后，问题出在哪一层基本就清楚了。这比凭感觉猜参数要快得多。