nfs挂载不传递umask，其生效位置在客户端进程创建文件时，服务端仅按exports权限和自身文件系统规则裁决；协同关键在于统一客户端umask、服务端目录setgid及属组配置。

NFS挂载本身不传递或修改 umask 值，umask 是客户端进程（如 shell、编辑器、脚本）在本地创建文件时起作用的内核级掩码，它只影响该客户端上新生成文件/目录的默认权限。NFS 协议不将 umask 作为挂载参数传输给服务端，服务端也不会按客户端的 umask 重算权限——但两端 umask 的协同效果，会通过「文件创建行为」间接体现出来，尤其在协作场景下容易出权限不一致问题。

关键在于：谁在哪儿创建文件？用什么身份？执行时的 umask 是多少？

---

NFS 挂载中 umask 实际生效的位置

• ✅ 客户端进程创建文件时（例如 touch, cp, vim 在挂载点下保存），使用的是客户端当前用户的 umask，决定新建文件的初始权限（再经服务端导出选项裁剪）
• ❌ 服务端不会读取或应用客户端的 umask；它只按 /etc/exports 中的权限选项（如 rw, no_root_squash）、文件系统实际权限、以及自身 umask（若服务端进程自己创建文件）来响应请求
• ⚠️ 若服务端启用 root_squash（默认），客户端 root 创建的文件会被映射为 nobody 用户，此时服务端自身的 umask 和属主属组策略才真正起主导作用

示例：
客户端用户 alice（主组为 dev），umask 002，挂载 /data/nfs 后执行：

cd /data/nfs  
touch hello.txt

→ 文件属主是 alice，属组是 dev，权限为 664（666 & ~002），前提是服务端允许组写（如 exports 中有 rw 且目录本身 g+w）

---

让两端 umask 表现“协同”的实操要点

• 统一客户端全局 umask（推荐）
  编辑 /etc/login.defs，设置：

  UMASK           002

  或通过 PAM：在 /etc/pam.d/common-session 加入

  session optional pam_umask.so umask=002

  → 所有普通用户登录后默认 umask 002，新建文件为 664、目录为 775

  

  稿定AI绘图

  稿定推出的AI绘画工具

  下载

• 服务端配合 setgid + 固定属组（核心稳定方案）
  仅靠 umask 不足以保证协作目录下文件属组自动继承。必须：

  • 对共享目录设 setgid：chmod 2775 /volume1/shared
  • 设定统一业务组（如 sharedgrp）并 chgrp sharedgrp /volume1/shared
  • 将所有协作用户主组设为 sharedgrp（usermod -g sharedgrp userX）
    → 此时无论客户端 umask 是 002 还是 022，只要目录有 setgid，新文件/目录属组必为 sharedgrp，且组可写（775/664）

• 避免依赖服务端 umask 的陷阱
  群晖 NAS 的 NFS 服务由内核 NFS daemon 处理，不走 shell 环境，因此 /etc/profile 或用户 shell 的 umask 对 NFS 写入无效。它的权限逻辑是：

  • 客户端传来的权限字（由客户端 umask 计算得出）
  • 服务端根据导出选项（如 sync, rw, no_root_squash）和底层文件系统权限做最终裁决
  • 若服务端目录本身 g-w，即使客户端写了 664，实际存到磁盘可能变成 644

• 挂载选项不能替代 umask，但可辅助行为控制
  虽然 -o umask= 不是合法 NFS 挂载参数（那是 mount.cifs 的用法），但可通过以下选项影响权限表现：

  • noac / lookupcache=none：禁用客户端缓存，确保权限变更实时可见（尤其多客户端场景）
  • nfsvers=3 或 nfsvers=4.2：不同版本对权限字段解释略有差异，v4 更严格遵循 RFC，建议生产环境固定版本
  • sec=sys（默认）：认证简单，权限映射直白；避免混用 krb5 等复杂安全模式增加调试难度

---

验证是否协同生效的三步检查法

1. 查客户端 umask

   umask  # 应显示 0002 或 0007 等

2. 查挂载点目录权限与属组

   ls -ld /data/testnfs  
   # 应看到 drwxrwsr-x+（含 s 位）且属组正确

3. 实测新建文件行为

   touch /data/testnfs/testfile  
   ls -l /data/testnfs/testfile  
   # 正确结果：-rw-rw-r-- 1 alice sharedgrp … testfile  
   # 错误信号：属组为 users 或 nobody，或权限为 644

若失败，优先检查：服务端目录是否 chmod g+s、客户端用户是否属于目标组、/etc/exports 是否含 no_root_squash（若需保留 root 权限）或 all_squash（若需统一降权）。