ACL权限生效需同时满足三条件：文件系统挂载启用acl、正确设置default ACL、umask与mask协同配合；缺一不可，且每步须手动验证。
ACL 权限不是“设了就生效”，关键得过三关：文件系统挂载选项、默认 ACL 设置、umask 与 mask 的配合。缺一不可。
确认文件系统是否真启用了 acl
很多用户执行 setfacl 没报错，但权限不生效，根源常在挂载选项没开 —— 内核支持 ≠ 实际启用。
- 运行
mount | grep "$(df . | tail -1 | awk '{print $1}')" | grep acl，输出含acl才算真正启用 - 若无输出，临时启用：
sudo mount -o remount,acl /shared（把/shared换成你的路径） - 永久生效需改
/etc/fstab，在对应行 options 字段追加acl，例如：UUID=xxx /shared ext4 defaults,acl 0 1 - 注意：
tune2fs -l /dev/sda1 | grep "Default mount options:"只看默认选项，不能代替实时挂载状态验证
用 setfacl 添加用户或组权限时的常见陷阱
直接加权限容易，但权限是否真落到目标对象身上，取决于语法细节和上下文。
- 给用户授权：用
setfacl -m u:alice:rwX /path，rwX中大写X更安全（目录必加 x，普通文件只对已有 x 位的加） - 递归设置要加
-R，但慎用：setfacl -Rm g:devteam:rwx /proj会覆盖所有子项原有 ACL，非必要不推荐 - 组名含空格必须引起来：
setfacl -m "g:app testers":r /log.txt，否则解析失败 - 执行后用
ls -l看权限串末尾是否有+；再用getfacl /path确认user:alice:rw-或group:devteam:rwx条目真实存在
让新文件自动继承 ACL：必须设 default ACL
只对现有文件设 ACL 没用，协作目录的核心是新建内容自动带权限 —— 这靠 default 规则，且仅对目录有效。
- 命令格式固定：
setfacl -d -m u:alice:rwX,g:devteam:rwx /shared/project（-d和-m顺序不能颠倒） - 执行后
getfacl /shared/project必须出现以default:开头的条目，如default:user:alice:rw- - default ACL 不影响已有文件，只管后续
touch、mkdir、cp等新建操作 - 若新建文件没继承，先检查父目录是否有
default:行，再确认 umask 是否为002（否则rw-可能被截成r--）
mask 是隐形天花板，常被 chmod 意外压低
mask:: 行决定所有命名用户/组权限的上限。它通常由 setfacl -m 自动更新，但一旦你用 chmod 改过权限，mask 就可能被锁死。
- 执行
getfacl /path查看mask::值，比如mask::r-x，那即使设了u:alice:rw-，实际也只剩r-x - 手动修复：
setfacl --recompute-mask /path，或显式重设：setfacl -m m::rwx /path - umask 影响新建文件权限位，mask 影响 ACL 权限生效上限 —— 两者都得盯住，少一个，ACL 就形同虚设
最易忽略的是：设完 default ACL 后不验证新建文件的实际 ACL，也不检查 mask 是否被 chmod 拉低。权限策略落地，靠的是每一步的手动验证，而不是命令返回 success。
