核心是清空acl回归标准权限，再统一容器与宿主机uid/gid：先setfacl -b /host/data清除acl，再用ls -ld确认目录属主uid/gid，启动时--user显式指定匹配值，dockerfile中固化同uid用户，必要时启用userns-remap增强隔离。
容器挂载宿主机目录时，ACL权限本身不是“解决方案”，而是**需要谨慎使用甚至主动清除的潜在风险点**。真正解决UID映射导致的权限受阻，核心在于让容器内进程的UID/GID与宿主机目录的实际属主/属组匹配，ACL只是在匹配基础上做补充控制，而非兜底手段。
先清空ACL，回归标准Unix权限
多数权限问题源于挂载目录被意外设置了宽松ACL（如setfacl -m u:1001:rwx /host/data），反而干扰了UID映射逻辑。ACL启用后，文件系统会叠加检查，容易引发掩码（mask）放大权限或冲突。
- 执行
setfacl -b /host/data彻底移除所有ACL条目，只保留user:、group:、other:三段传统权限 - 确认输出中不再出现
user:xxx:、group:yyy:或mask::等行：getfacl /host/data - 此时权限判断完全由UID/GID比对决定，行为可预测、易调试
让容器UID与宿主机目录属主一致
ACL无法绕过“谁 owns 这个目录”这个根本问题。如果宿主机目录属主是dev:dev（UID=1000, GID=1000），容器就必须以UID=1000运行，否则无论ACL怎么设，Linux内核都会拒绝访问。
- 查宿主机目录归属：
ls -ld /host/data→ 确认UID/GID数字 - 启动容器时显式指定：
docker run -v /host/data:/data --user 1000:1000 image - 若用Dockerfile构建，提前创建同UID用户：
RUN groupadd -g 1000 dev && useradd -u 1000 -g dev dev
ACL仅用于补充非属主场景
只有当容器必须以**非目录属主的UID运行**（例如多租户隔离、安全沙箱），且又需访问该目录时，才考虑用ACL做最小化授权——但必须严格遵循最小权限原则。
- 只添加精确UID条目：
setfacl -m u:1001:rw- /host/data（注意末尾是rw-，不含x） - 禁用默认继承：
setfacl -k /host/data，防止子目录自动获得相同ACL - 收紧mask：
setfacl -m m::r-- /host/data，确保ACL实际生效权限不超预期 - 验证：
getfacl /host/data中应仅有user::、group::、other::和你手动加的user:1001:
配合userns-remap堵住映射漏洞
单纯靠ACL或--user仍可能被绕过。启用user namespace remap后，容器内UID=1001实际映射为宿主机高位UID（如100100），即使ACL误配成u:1001:rwx，也不会影响真实业务账户。
- 编辑
/etc/docker/daemon.json，加入"userns-remap": "default" - 重启Docker：
sudo systemctl restart docker - 确认生效：
docker info | grep "User Namespace"应显示enabled - 此时再结合
--user 1001:1001启动，宿主机上看到的是ps aux里UID=100100的进程
