搞 NFS 的朋友迟早都要和/etc/exports这张表打交道。它决定了谁能挂载你的共享目录、挂载后是只读还是可写、root 用户有没有特殊待遇、写入请求什么时候真正落盘……但大部分人配完就忘真出问题才开始翻 man 文档然后被一堆默认值和优先级搞昏头。尤其像 Ubuntu 24.04、Debian、RHEL 这些系统NFS 服务端行为细节还不完全一样网上抄来的配置可能今天能用、明天换台机器就翻车。这篇文章就把/etc/exports里那些不写就生效的默认参数、多条目叠加时的优先级规则以及我踩过的坑一次讲透。不绕弯子直接按配置格式 → 默认值 → 优先级 → 验证方法 → 排错的顺序来适合正在搭 NAS、维护集群共享存储、或者只是想让两台 Linux 机器互通目录的朋友。看完你就能自己判断一段配置为什么会以某种参数组合生效而不是靠猜。1. 先说清楚 /etc/exports 这张参数表到底在管什么1.1 文件格式与基本语法/etc/exports的作用非常纯粹告诉内核态的 NFS 服务端nfsd 和 rpc.mountd哪些目录可以导出、允许哪些客户端访问、访问时附带哪些行为限制。每行格式非常固定导出目录 客户端1(参数1,参数2) 客户端2(参数3)例如/export/data 192.168.1.0/24(rw,sync,no_subtree_check) 10.0.0.5(ro,no_root_squash)这里有几个初学者容易忽略的点。第一导出目录和客户端之间必须用空格或 Tab 分隔多个客户端条目之间也是空格分隔。第二每个客户端后面的括号紧贴着主机名或 IP中间不能有空格。第三如果某个客户端不写括号等于不附加任何显式参数全部走默认值——这是很多人不理解的默认值的起点。顺便说一句/etc/exports里可以写注释用#开头。但这个文件不像 nginx 那样支持 include 嵌套所以你的全部导出规则基本都在一个文件里乱写一行就有可能导致整个 NFS 服务起不来。从man exports的角度看整个文件其实描述了一种映射关系某个目录 → 若干客户端 → 每个客户端对应的参数集合。而参数集合并不是全量状态它只是增量状态没写出来的参数由服务端根据内核默认值补齐。这就是默认值为什么重要——你以为没写ro就是可读写不默认是ro只读。1.2 主机匹配规则里的隐性优先级很多人以为/etc/exports的客户端字段只支持 IP其实支持的东西比想象中多单台主机192.168.1.10或主机名nas-client网段192.168.1.0/24或192.168.1.*通配符*.example.com、*匹配所有主机反向解析后的域名匹配client.example.com这里就出现了一个核心问题如果同时存在192.168.1.0/24(ro)和192.168.1.10(rw)那 192.168.1.10 这台机器到底按哪个参数挂载答案是精确匹配优先于网段匹配网段匹配优先于通配符匹配。也就是说NFS 服务端在处理挂载请求时会从所有导出条目中挑一个最贴近请求来源的规则来使用而不是按文件里的书写顺序从上到下选第一条。这个优先级是隐含的但作用极其关键很多生产环境权限事故就是这么来的你写了一个很宽的*(rw)同时又希望特定 IP 走特殊策略结果因为具体条目的优先级不同行为完全出乎意料。所以我的个人习惯是永远把最精确的条目写在最上面把宽泛条目写在最下面。虽然逻辑上精确匹配无论如何都会优先但这样写能让人一眼看清规则范围减少误判。更重要的是后文会提到不同版本 nfs-utils 在合并规则时可能存在细微差异而精确优先这个原则在绝大多数版本中都能成立。1.3 为什么一个条目能叠加这么多参数一个导出条目可以同时包含rw,sync,no_subtree_check,root_squash,secsys等一长串参数。这些参数大致分三类访问控制类ro/rw、root_squash/no_root_squash、all_squash/no_all_squash、anonuid/anongid决定谁能写、写的时候以什么身份写。语义与性能类sync/async、wdelay/no_wdelay决定服务端何时把数据提交到本地文件系统。协议与路径检查类secure/insecure、subtree_check/no_subtree_check、fsid、sec决定客户端以什么样的端口、安全协议和路径语义来访问。这些参数之间不是互斥关系而是可以同时生效的不同维度。比如rw,sync不等于只要同步写入就不要权限控制了权限控制仍然由root_squash和本地文件系统权限决定。理解这个维度划分是理解优先级的前提——你不可能用一个参数去覆盖另一个参数因为它们各管一段。2. 参数默认值全解你不写参数时系统替你做了什么决定这是整个/etc/exports里最容易让人产生迷惑的地方。很多教程教你配 NFS 的时候直接写rw,sync,no_subtree_check,nohide一条龙但没人告诉你其中哪几个是必需的、哪几个其实不写也行、不写会得到什么结果。我先把常用参数默认值汇总成一张表再逐个拆解。参数默认值不写时的实际效果注意事项ro/rwro客户端只能只读挂载写入请求直接拒绝需要读写时务必显式写rwroot_squash/no_root_squashroot_squash客户端的 root 被映射为匿名用户 nobody想保留 root 权限才需要显式写no_root_squashall_squash/no_all_squashno_all_squash只有 root 被压缩普通用户保留自己的 UID/GID公共目录常配all_squash,anonuid...sync/asyncsync现代内核服务端确认写请求前必须落盘老系统和某些 UNIX 默认async需要确认wdelay/no_wdelaywdelay服务端合并小写入稍微延迟提交no_wdelay只有在sync下才有意义subtree_check/no_subtree_check现代内核实际为no_subtree_check不检查导出子目录与整个文件系统子树的关系显式开subtree_check可能带来性能开销secure/insecuresecure客户端必须使用 1024 以下保留端口Windows/容器客户端常常需要insecuresecsys/seckrb5*secsys基于传统 UID/GID 认证不加密内网场景够用外网建议考虑加密anonuid/anongid65534nobody匿名映射后的 UID/GID可配合all_squash使用2.1 访问权限与控制类的默认值ro/rw的默认值是ro。这条很容易理解但从安全角度也最容易出问题如果你只写了/share 192.168.1.10那这台机器能挂载目录但只能读。很多新手配完发现不能写第一反应是改目录权限却发现改了没用就是因为服务端导出参数还是ro。记住NFS 服务端导出的ro是硬限制客户端即使挂载时写了mount -o rw照样写不进去。root_squash的默认是开启。这个机制的作用是把客户端的 UID 0root在服务端映射为 nobody一般是 65534防止客户端 root 在共享目录里为所欲为。这个默认值我强烈建议保留绝大多数场景都不该关。很多人在测试时为了省事配了no_root_squash结果客户端一条rm -rf就能把自己共享目录删空教训极其惨痛。all_squash的默认是关闭。普通用户非 root访问时服务端看到的是客户端传来的原始 UID/GID。这有一个隐含前提服务端本地必须存在相同 UID 的用户否则文件属主会变成一串数字。这是 NFS 无认证机制的典型缺陷。若想规避可以配all_squash把所有人映射成同一个账号但代价是所有用户共享权限只适合公共目录。2.2 写入语义类的默认值sync的意思是NFS 服务端收到客户端写入请求后必须把数据写进服务端本地文件系统并返回确认客户端才会认为写入完成。这个默认值在现代 Linux 内核里已经是同步的好处是数据可靠性高代价是写入性能下降。而async允许服务端先把数据放在内存缓存里立刻给客户端返回成功。大量基准测试里async的性能可以比sync高一截但一旦服务端突然断电客户端以为已经写入的数据可能根本没落盘甚至可能造成文件系统元数据损坏。wdelay的默认是开启。当 NFS 服务端在短时间内连续收到多个写入请求时会把它合并成一两笔大的写入再提交减少磁盘 seek提升吞吐。no_wdelay则是每个请求都单独提交适合对写入延迟敏感的应用。有一点必须注意wdelay只对sync模式有意义。如果你配了asyncwdelay/no_wdelay根本没有效果因为数据本来就不立即提交。2.3 安全与协议类的默认值secure的默认是开启它要求客户端源端口小于 1024。这个设计源自早期 NFS 的保留端口即信任逻辑。但现实中很多客户端并不走保留端口比如某些 Windows NFS 客户端、容器网络环境、以及 NAT 环境下的请求端口往往大于 1024。如果你不幸遇到明明导出规则没问题客户端一挂载就 Permission denied的情况八成是secure在作祟这时候要给客户端加一个insecure参数放行。subtree_check的默认值是现代内核倾向于不开启。这个参数的本意是当一个导出目录只是文件系统的子目录时服务端需要额外检查请求的文件是否真的在导出目录的子树内防止用户通过硬链接/重命名绕过限制。问题是这个检查在目录频繁重命名时容易产生Stale file handle错误而且有一定性能开销。所以内核 2.6.24 之后逐步把默认改成了no_subtree_check。我的建议很简单别主动开subtree_check除非你明确知道自己在做什么。secsys是默认的 RPC 安全模式完全基于明文的 UID/GID 传递不加密、不校验票据。在内网可信环境没问题跨公网或不可信网络至少要懂krb5系列参数但这套需要 Kerberos 基础设施实际部署成本不低。2.4 默认值背后的内核逻辑为什么这些默认值这么设计核心原因是 Linux NFS 服务端在内核里维护了一套安全优先、性能靠后的基线。你什么都不写它宁可让共享目录只读也不让客户端 root 拥有特权宁可写入慢一点也要保证确认过就算数宁可对客户端端口要求严格也不要让匿名来源随意访问。这套默认值对大多数内网小规模共享是能用的最安全配置。但一旦你想让共享目录真正干活比如给开发机做读写存储、给 Kubernetes 节点挂 PV就必须显式地打开rw和其他参数——这不叫覆盖默认值而叫你已经把默认的安全基线调整到了业务需要的水平。3. 优先级规则拆解多条目合并时NFS 到底听谁的3.1 显式参数与默认值的优先级显式就是赢家同一维度内显式指定的参数永远高于默认值。比如默认是ro你写了rw那实际生效是rw默认是root_squash你写了no_root_squash那 root 就不再被压缩。这在大多数人的直觉里没问题但要注意显式参数的胜利只在一个条目的作用域内有效。如果你把同一个目录导出给两个不同客户端一个写了rw、一个没写那没写的客户端仍然走ro默认值不会因为另一个条目写了rw就受影响。这个条目间互不影响的特性很容易被初学的人忽略。我见过有人把两个网段写在同一行/export 192.168.1.0/24(rw) 10.0.0.0/24他们的想法是10.0.0.0/24 应该跟着前面的 rw 走但实际结果是 10.0.0.0/24 这个条目没有任何显式参数它只会得到只读权限。如果想让两个网段都读写必须写成/export 192.168.1.0/24(rw) 10.0.0.0/24(rw)或者干脆把两个网段合并成一条规则。3.2 客户端匹配的优先级精确匹配 网段 通配符前面提过NFS 选择客户端规则时采用最具体匹配优先。我把优先级从高到低列一下优先级匹配方式示例高精确 IP / 精确主机名192.168.1.10中网段 / IP 通配符192.168.1.0/24、192.168.1.*低域名通配符*.example.com最低全匹配*这意味着就算*这一行写在文件最上面来自192.168.1.10的请求如果也有一个精确匹配条目服务端依然会选中精确匹配条目。这个逻辑比较符合直觉但也有坑比如你写了192.168.1.0/24(ro)和192.168.1.10(rw)那 192.168.1.10 能写其他机器只能读但如果你写的是192.168.1.0/24(rw)和192.168.1.10(ro)那 192.168.1.10 反而被单独降级成只读其他机器可读可写。条目的覆盖面越窄优先级越高这个特性能用来做例外控制但也容易被人反向用错。3.3 同一导出目录多次出现时的合并行为这里有个非常实际的问题如果同一个目录在/etc/exports里出现多行服务端会怎么处理以 nfs-utils 的实际行为来看exportfs会把指向同一目录的多个条目合并成一个内部结构每个客户端保持自己的参数集互不覆盖。比如/export/data 192.168.1.10(rw,sync) /export/data 192.168.1.20(ro,no_root_squash)最终效果等于/export/data 192.168.1.10(rw,sync) 192.168.1.20(ro,no_root_squash)但如果同一个客户端在两行里出现了两次行为就要小心了。比如/export/data 192.168.1.10(rw) /export/data 192.168.1.10(ro)这种情况下不同版本的exportfs表现不完全一致有的以后写入的为准有的报 exportfs: duplicate export 警告。我自己实测过 Ubuntu 22.04 和 CentOS 7 上的行为基本是后者覆盖前者但千万不要依赖这个行为。把同一个客户端写两行属于十足的坏味道既难读又难维护还有版本差异风险。正确的做法是合并成一行把参数写在一个括号里。3.4 参数本身的覆盖规则最后的逗号参数说了算吗如果单个客户端条目里同时写了冲突的参数比如rw,ro或root_squash,no_root_squash哪个生效从 exports 解析器的一般行为看同一维度内后出现的参数覆盖前一个。比如rw,ro最终效果是roroot_squash,no_root_squash最终效果是no_root_squash。但这里我必须给出一个实操建议永远不要这样写。冲突参数放一起没有任何正当理由它不提高可读性反而让阅读者必须去猜解析器的实现细节。我自己遇到过一次非常隐蔽的事故就是配置文件里写了rw,no_root_squash,ro本意是rw 和 no_root_squash结果最后一个ro把整个条目的写权限吞掉了客户端怎么测都是只读排查了半小时才发现是参数顺序问题。4. 实操配置与验证让参数优先级现出原形4.1 一个覆盖多场景的完整配置示例纸上谈兵没意思直接给一个我实际用过的配置骨架。假设服务器 IP 是 192.168.1.100共享目录有两个/srv/nfs/share是普通项目目录/srv/nfs/backup是备份目录。/srv/nfs/share 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash) /srv/nfs/share 10.0.0.5(ro,sync,no_subtree_check) /srv/nfs/backup 192.168.1.0/24(ro,sync,no_subtree_check) /srv/nfs/backup 192.168.1.100(rw,sync,no_subtree_check,no_all_squash)这里有几层心思/srv/nfs/share给内网 192.168.1.0/24 读写同时给 10.0.0.5 只读。10.0.0.5 是一条精确匹配所以它不受 192.168.1.0/24 那条rw影响。我把no_root_squash加在了内网写规则上理由是这台共享服务器专门给开发环境用开发人员都是直接 root 操作容器省得出现明明有权限但写完文件属主变成 nobody的问题。如果你做的是生产环境或者公共 NAS我强烈不建议抄这个参数这是场景化取舍。/srv/nfs/backup只读共享给整个网段唯独服务器自己可以读写用于本地备份灌入。这个例子里没有写fsid0因为它不是 NFSv4 的伪文件系统根普通子目录导出不需要。如果客户端挂载/srv/nfs/share时报No such file or directory才需要考虑是不是 NFSv4 需要把导出目录放在伪文件系统根下或者用fsid0指定根目录。4.2 重载与状态查看exportfs 系列命令的正确用法改完/etc/exports后第一反应千万不要是重启nfs-server服务。重启会短暂中断所有正在挂载的客户端生产环境下这等于人为制造故障。正确姿势是使用exportfs命令热重载sudo exportfs -ra-r表示重新导出所有目录-a表示导出/取消导出所有配置。执行后服务端会重新读取/etc/exports应用新的规则已挂载的客户端在重载过程中一般不受影响。如果只是新增了一条规则也可以更精细地只导出某个目录sudo exportfs -o rw,sync,no_subtree_check 192.168.1.10:/srv/nfs/share不过日常运维我更推荐exportfs -ra简单粗暴且不易出错。重载后立刻用exportfs -v检查实际生效的参数sudo exportfs -v输出类似/srv/nfs/share 192.168.1.0/24(rw,sync,wdelay,no_root_squash,no_subtree_check,secsys,rw,secure,no_all_squash) /srv/nfs/share 10.0.0.5(ro,sync,wdelay,root_squash,no_subtree_check,secsys,ro,secure,no_all_squash)注意exportfs -v输出的参数列表里有很多你并没有显式写的参数比如wdelay、secsys、secure、no_all_squash它们就是内核补全的默认值。这就是观察默认值最直接的手段。对比两个条目你就能看到root_squash和no_root_squash的差异也能看到 10.0.0.5 那条里ro补进去了而 192.168.1.0/24 那条里是rw。4.3 从客户端验证参数真实的生效值光在服务端看还不够我习惯在客户端也做一轮验证。首先看能不能看到导出列表showmount -e 192.168.1.100能列出目录说明 rpc.mountd 正常工作。接着挂载sudo mkdir -p /mnt/test sudo mount -t nfs 192.168.1.100:/srv/nfs/share /mnt/test挂载后查看实际挂载参数mount | grep nfs但这里有个容易搞混的点客户端 mount 输出的参数比如rw,relatime,vers4.2只反映客户端自身挂载参数不直接反映服务端 exports 参数。要验证服务端的 rw/ro 是否生效最简单的办法是实际写入测试touch /mnt/test/write_test如果No space left on device提示不是空间问题而是只读文件系统touch会报Read-only file system。此时再去服务端用exportfs -v确认该客户端的条目是否真的是ro。另一个更有意思的验证手段是在服务端查看内核导出的实际状态cat /proc/fs/nfsd/exports这个文件展示的是 nfsd 内核模块最终接受的那份导出表和参数标记比exportfs -v更接近内核判决结果。输出里会出现类似(rw,sync,wdelay,no_root_squash,no_subtree_check,secsys,secure,no_all_squash)这样的 flags它是排错时最可信的参考之一。5. 常见问题排查与避坑实录5.1 root_squash 引发的有 rw 还是写不了这是 NFS 排错里最经典的一幕。现象是客户端挂载成功touch测试文件结果Permission denied。服务端配置明明写了rw目录权限也是 777怎么就写不了如果你在客户端通过 root 操作那么问题多半出在root_squash上。客户端 root 发起的写请求到服务端后身份被压成了 nobodyUID 65534而目录即使权限是 777也可能因为它所属的父目录某级权限限制比如/srv是 755nobody 无法进入/srv/nfs/share的上级目录导致最终写失败。排查顺序我建议这样# 客户端确认当前 id id # 服务端确认该客户端实际拿到的匿名身份 grep nobody /etc/passwd # 服务端检查导出目录各级父目录的权限 namei -l /srv/nfs/sharenamei这个命令很少有人用但排查 NFS 权限问题特别好使它会把路径每一级的权限列出来一眼就能看出 nobody 在哪一层被卡住。解决办法通常是调整父目录权限或改用all_squash,anonuid某个现有用户,anongid某个现有组把匿名身份固定到有权限的账号上。不到万不得已别上no_root_squash尤其是生产环境。5.2 no_subtree_check 与 Stale file handleStale file handle是 NFS 用户最熟悉的报错之一。出现这个错误常见原因有两个一是客户端挂载了某个目录后服务端把目录删掉或者重命名了客户端的文件句柄指向了不存在的对象二是在旧内核上开了subtree_check导致目录被重命名后服务端产生错误的文件句柄判定。我在 Ubuntu 24.04 上实测默认导出不写subtree_check相关参数时基本不会触发这个错误。但如果你从老教程里抄来了subtree_check参数并且在客户端频繁做了目录重命名的操作那就要小心了。处理办法很简单一个是客户端重新挂载另一个是在服务端把显式的subtree_check改成no_subtree_check并重载导出。现代内核2.6.24 之后默认就是no_subtree_check所以正常情况下你真的不需要手动写它。5.3 async 的性能甜头与数据风险如果你追求性能async确实立竿见影尤其是有大量小文件写入的场景。但我不建议在存放重要数据的目录上使用async。它意味着服务端把数据放进缓存就返回成功一旦断电缓存丢失客户端会认为写入已经完成于是产生静默数据损坏。这类问题比挂载失败可怕得多因为它不报错等你发现的时候数据已经错了。如果你一定要用async至少把数据库、代码仓库这类对一致性敏感的数据放出去。我在一些视频转码、日志采集这类丢了可以重来的场景里用过async性能确实好但每次想到可能丢数据还是心有余悸。现在我的原则是默认sync除非性能指标明确不达标并且能接受极端情况下的数据丢失否则不碰async。5.4 不同发行版/版本之间的默认值差异最后提一个容易踩的暗坑不同发行版的 nfs-utils 版本不同默认值并不完全一致。老一点的系统比如 CentOS 6内核 2.6.32里async在某些配置模板中可能是默认行为而现代 Ubuntu 22.04 / 24.04 上sync是常态。subtree_check的情况也类似CentOS 7 上有时你会在exportfs -v里看到subtree_check被显式补出来而在 Ubuntu 24.04 上又变成no_subtree_check。所以最稳妥的做法不是记忆某个版本的默认值而是每次配置完都用exportfs -v和cat /proc/fs/nfsd/exports检查一遍实际生效值。让数据说话而不是让记忆替你拍板。另外Ubuntu 上如果你发现配了 NFSv4 但客户端挂载总是落到 NFSv3记得检查是不是没装nfs-kernel-server而只装了nfs-common前者才提供服务端能力。最后再分享一个小技巧/etc/exports里我习惯给每个条目末尾都显式写出三个保命参数——sync、no_subtree_check、no_root_squash仅当确实需要 root 写权限时。虽然它们大部分本来就是现代内核默认值但显式写下去了每次exportfs -v时都能一眼确认不会因为系统版本升级导致默认值变化而悄悄改变行为。这个习惯救过我不少次建议你也试试。