ACL是唯一能为特定用户或组单独设权限的机制，传统chmod/chown无法实现；ls -l显示末尾“+”表示已设ACL，但实际权限受mask限制，需用getfacl查看完整规则及effective权限。
ACL 是唯一能实现“给某个特定用户或组单独设权限”的机制，传统 chmod 和 chown 无法做到这点。如果你需要让 userA 对 /shared/report.txt 有读写权、userB 只读、而其他人无权访问——就必须用 setfacl，不是改 umask 或 chmod。
如何判断一个文件是否已启用 ACL
执行 ls -l 后，权限字符串末尾若出现 +（如 -rw-rw-r--+ ），说明该文件已设置 ACL；若仍是点号（.）或无符号，则未启用。
注意：+ 只表示“存在 ACL 规则”，不代表规则一定生效——可能被掩码（mask）限制了实际权限范围。
- ACL 规则本身不改变
ls -l显示的 u/g/o 权限位，它是在那之外叠加的 - 目录启用 ACL 后，新创建的文件默认不继承 ACL，除非同时设置了默认 ACL（
setfacl -d） -
getfacl filename才能真正看到所有规则，包括 mask 和 effective 权限
setfacl 添加单用户/单组权限的正确写法
语法必须带 -m（modify），且用户/组名前要加 u: 或 g: 前缀，否则命令会静默失败或报错 Invalid argument。
常见错误写法：setfacl -m userA:rw- file.txt（缺前缀，会被当成用户名为 “userA:rw-” 的非法用户）
- 给用户 userA 读写权限：
setfacl -m u:userA:rw- file.txt - 给组 devs 读写执行权限：
setfacl -m g:devs:rwx dir/ - 对目录递归设置，并让子文件继承：
setfacl -R -m g:devs:rwx /shared/project/ - 设置默认 ACL（新文件自动获得）：
setfacl -d -m g:devs:rwx /shared/project/
mask 掩码导致权限“看似设置成功却无效”的原因
ACL 中的 mask 是一个隐式权限上限，它会截断所有 named user/group 的实际生效权限。比如你用 setfacl -m u:userA:rwx 设置了 rwx，但当前 mask 是 r-x，那么 userA 实际只有 r-x。
查看 mask：运行 getfacl file.txt，找 mask::r-x 这一行
- 手动扩大 mask：
setfacl -m m:rwx file.txt（m: 表示 mask） - 更稳妥的做法：每次增删 ACL 后，用
setfacl -n file.txt清除旧 mask，再重新设规则，系统会自动计算最小必要 mask - mask 不影响 owner 和 other 的权限，只约束 named users/groups
ACL 权限在目录和文件上的继承差异
ACL 本身不自动继承，但可通过 -d（default）选项为目录设置默认规则，仅对后续新建项生效，对已有文件/子目录无效。
- 设置默认 ACL 后，新建文件继承的是
mask & default_permissions，不是直接复制 default 权限 - 普通文件不能设 default ACL（
setfacl -d对文件报错Operation not supported） - 删除整个 ACL：
setfacl -b file.txt；只删某条：setfacl -x u:userA file.txt - 备份 ACL 规则：
getfacl dir/ > acl_backup.txt；恢复：setfacl --restore=acl_backup.txt
ACL 的核心复杂点不在命令本身，而在于 mask 的隐式干预和 default 规则的生效边界。很多人反复设置却没效果，问题八成出在 mask 被忽略，或误以为 -R 能让子文件“自动拥有默认 ACL”。真正落地时，先 getfacl 看现状，再动 setfacl，最后仍要用 getfacl 验证 effective 权限——别信 ls -l 的 + 符号。
