mask 是 acl 中非属主、非 other 条目的实际权限上限，会随 chmod 或 setfacl 动态重算；常见导致写权限丢失的操作包括 chmod 缩权、nfs 未刷新、setfacl -r 未带 --mask、先设 default 再改 chmod；确保写权限需用 --mask 参数自动重算或显式 setfacl -m m::rwx；修复时用 getfacl 定位 mask 缺 w 并执行 setfacl -m m::rwx。
Mask 值自动改变导致写权限失效，本质不是“bug”，而是 ACL 的设计机制在起作用：mask 是非属主、非 other 条目的**实际权限上限**，它会随 chmod 或部分 setfacl 操作动态重算。只要理解它的触发逻辑并主动干预，就能稳定保全写权限。
哪些操作会悄悄压低 mask 导致写权限丢失
常见但容易被忽视的操作包括：
-
chmod 缩小组/其他权限位：例如对已有 ACL 的目录执行
chmod 755 dir，系统会把 mask 自动设为r-x（因为组权限是 r-x），即使你之前给 user:alice 设了 rwx，她也立刻失去写权 - 用旧版工具或 NFS 挂载后未刷新：某些环境不自动同步 mask，导致新设的 w 权限始终被旧 mask 截断
- setfacl -R 递归设置时没带 --mask：批量加权限后，mask 未重算，仍维持旧值（比如 --- 或 r--）
-
先设 default ACL，再改基础权限：比如先
setfacl -d -m u:dev:rwx dir，再chmod 750 dir，后者会把 mask 降为 r-x，导致新建文件里 dev 实际只有 r-x
如何确保写权限不被 mask 锁死
关键不是阻止 mask 变化，而是让它始终覆盖你需要的权限位（尤其是 w）。推荐两种可靠做法：
-
加 --mask 参数让系统自动重算：每次用
setfacl -m添加含 w 的规则时，顺手加上--mask，例如：setfacl --mask -m u:jenkins:rwX /shared
这样 setfacl 会扫描所有 ACL 条目，取最大权限（含 w）作为新 mask -
显式设置 mask 值（更可控）：如果已知所有 ACL 都需要 w，直接定死：
setfacl -m m::rwx /shared
对目录还要同步默认 mask：setfacl -d -m m::rwx /shared
发现写权限失效后快速定位和修复
别猜，用 getfacl 直接看证据：
- 运行
getfacl /path，检查两处：
– 是否有mask::行，且不含w（如mask::r-x）
– 对应用户条目后是否标着#effective:---或#effective:r--（说明 w 被截断） - 修复只需一行命令：
setfacl -m m::rwx /path
如果是目录，补上默认 mask：setfacl -d -m m::rwx /path - 验证：切到目标用户身份测试写操作，例如：
su - jenkins -c "touch /shared/test"
长期避免 mask 干扰的配置习惯
把 mask 纳入权限设计环节，而不是事后补救：
- 设 default ACL 后，必须紧跟 mask 设置：例如
setfacl -d -m u:deploy:rwx /data && setfacl -m m::rwx /data && setfacl -d -m m::rwx /data - 运维脚本中，避免混用 chmod 和 setfacl；如需调整基础权限，改用
setfacl -m配合--mask - 定期检查关键目录的 mask 状态，尤其在部署或权限变更后：
getfacl /shared | grep -E "^(mask|user:|group:)"
