应立即收紧宿主机ACL配置：①用getfacl检查并移除非必要user/group条目；②仅添加容器所需UID的精确rw-权限；③执行setfacl -k禁用默认继承；④配合--user和userns-remap双重约束，禁用执行位。
排查 ACL 权限在 Docker 完卷映射中的兼容性问题，核心是确认容器能否以预期身份访问挂载目录，且不因 ACL 规则引发越权或拒绝访问。重点不在“有没有 ACL”，而在“ACL 是否与容器运行用户精确匹配、是否引入隐式风险”。
确认挂载路径是否启用 ACL 并识别宽松条目
先验证目标目录是否启用了 ACL，再检查是否存在非必要授权：
- 执行 getfacl /host/data 查看完整权限列表，重点关注 user:、group: 和 mask: 行；
- 若存在 user:otheruser:rwx 或 group:dev:rwx 等非业务必需条目，即为兼容性隐患点；
- 特别注意 mask::rwx —— 它会放大所有命名用户/组的实际权限，应降为 mask::rw- 或 mask::r-x，仅保留最小必要位。
验证容器用户 UID/GID 与 ACL 条目的实际映射关系
容器内进程的 UID 必须在 ACL 中有显式、精确的读写权限，不能依赖组继承或 mask 放大：
- 用 id -u 查容器内运行用户的真实 UID（如 1001），不要只看用户名；
- 检查 getfacl /host/data 输出中是否有 user:1001:rw- 条目；
- 若只有 group:app:rwx 但容器 UID 1001 不属于该组，或组权限被 mask::r-- 截断，则实际无写权限；
- 避免使用 default:user::rwx 这类默认 ACL，它会干扰子目录权限继承逻辑。
排除 SELinux/AppArmor 和 NFS 等叠加机制干扰
ACL 只是权限模型的一层，SELinux、NFS root_squash 或容器 user namespace remap 都可能覆盖或限制其效果：
- 在 SELinux 启用系统（如 CentOS）上，即使 ACL 允许，也可能报 Operation not permitted，临时加 :Z 挂载标志测试：docker run -v /host/data:/data:Z image；
- 若挂载的是 NFS，需确认服务端 /etc/exports 中是否启用 root_squash，以及客户端挂载时是否用 uid=1001,gid=1001 显式映射；
- 启用 userns-remap 后，容器内 UID 1001 实际映射为宿主机高位 UID（如 100100），此时 ACL 中必须针对该高位 UID 授权，而非容器内看到的 1001。
用最小权限组合验证最终行为
真正有效的配置是 ACL + 用户指定 + 执行位控制三者协同：
- 启动容器时强制指定用户：docker run -v /host/data:/data --user 1001:1001 image；
- 宿主机上禁用执行位：chmod -x /host/data，再用 ACL 补回读写：setfacl -m u:1001:rw- /host/data；
- 禁用默认继承防止扩散：setfacl -k /host/data；
- 最后在容器内执行 touch /data/test && ls -l /data/test，确认可写且属主 UID 匹配。
