ACL权限最终生效取决于内核检查顺序：先匹配属主/属组，再查ACL条目并与mask取交集，最后回落UGO；mask是权限上限过滤器，ACL条目权限需与mask按位与才为实际权限。
排查 ACL 与传统权限冲突，核心不是“看谁权限大”，而是确认实际生效权限由哪一层最终决定。ACL 和 UGO 权限共存时，内核会按固定顺序检查：先匹配用户/组身份 → 查 ACL（若有）→ 取 ACL 中对应条目与 mask 的交集 → 再 fallback 到传统属主/属组/其他位。冲突往往表现为“明明 setfacl 加了 rwx，却 still Permission denied”。
查清当前路径上所有权限层是否完整启用
很多问题卡在 ACL 根本没生效——文件系统未挂载 acl 选项、mask 被忽略、或路径中某级目录缺少执行权限。
- 确认文件系统支持 ACL：
tune2fs -l $(df . | tail -1 | awk '{print $1}') | grep "Default mount options"，输出必须含 acl - 检查挂载参数：
mount | grep "$(df . | tail -1 | awk '{print $1}')" | grep acl，若无 acl，需 remount 或改/etc/fstab - 对目标文件及每一级父目录执行
ls -ld，确保路径中每个目录都有 x（执行）位（否则连进入都失败，ACL 完全不触发）
用 getfacl 看清 mask 如何限制 ACL 实际效果
ACL 条目写的权限 ≠ 最终生效权限。mask 是一道“权限上限过滤器”，所有非属主的 ACL 权限（包括 user:xxx 和 group:xxx）都会和 mask 做 & 运算。
- 运行
getfacl /path/to/file，重点看 mask:: 行和 user:xxx: 行 - 例如：user:alice:rwx + mask::r-x → alice 实际只有 r-x（w 被 mask 拦掉）
- 若 mask 过窄，用
setfacl --mask -m m::rwx /path手动扩大（但需评估安全影响）
验证真实访问链路，而非只看静态配置
权限检查是动态过程：进程 UID/GID → 匹配属主？→ 否 → 匹配属组？→ 否 → 查 ACL 中是否有该 UID 条目？→ 有 → 与 mask 取交集 → 再检查路径各层 x 位。
- 用目标用户身份登录：
sudo -u username bash，再尝试操作（如cat file、ls dir） - 若失败，逐级
ls -ld /a /a/b /a/b/c，确认每级目录对当前 UID 是否可进入（x 位） - 用
strace -e trace=openat,stat追踪系统调用，直接看到 errno（如 EACCES 表示权限拒绝，ENOENT 表示路径不存在）
区分“ACL 未生效”和“ACL 与 UGO 逻辑矛盾”
有时 ACL 和传统权限看似冲突，实则是配置意图错误。比如：
- 给 user:alice:rwx，但文件属主是 alice → 此时走的是 user:: 段，ACL 中的 user:alice 不参与判断
- 给 group:dev:rwx，但当前用户不在 dev 组，且未在 ACL 中单独添加该用户 → ACL 无效，回落到 other:: 段
- 设置了 default ACL，但新建文件权限仍不对 → 检查 umask 是否覆盖了默认权限（default ACL 提供模板，umask 仍会按位取反过滤）
