bind mount 下容器内 root 无法访问宿主机 acl 限制目录，因内核透传权限检查；需在宿主机显式授权 uid 0、改用组继承 acl 或禁用 acl，最优解是 uid 对齐避免 root 依赖。
在 bind mount 场景下，宿主机目录设置了严格的 acl（如 `setfacl -m u:1000:r-x /host/path` 但未给其他用户权限），会导致容器内以 root（uid 0）运行的进程无法访问——因为 linux 内核在 bind mount 中不映射 uid，而是直接透传宿主机的文件权限检查逻辑。宿主机上 uid 0（root）可能被 acl 显式拒绝，或因“other”权限缺失而 fallback 失败。
确认 ACL 是否真正阻断了 root 访问
先在宿主机执行：
-
getfacl /host/path —— 查看是否含
user::---或other::---，或存在mask::---限制实际生效权限 - sudo -u root ls -l /host/path —— 模拟容器内 root 行为，验证是否真被拒（若报 Permission denied，即 ACL 生效）
绕过 ACL 限制的实用方案
ACL 是宿主机层面的控制，容器无法绕过，必须从宿主机侧调整。推荐以下三类操作：
-
显式授予 root 访问权：运行 sudo setfacl -m u:0:rwx /host/path（对目录本身）；若需递归，加
-R，并确保 mask 足够宽：sudo setfacl -m m:rwx /host/path -
改用默认 ACL + 组继承：创建专用组（如
docker-data），把宿主机目录属组设为此组，再让容器内 root 加入该组（通过--group-add），最后用setfacl -d -m g:docker-data:rwx /host/path设置默认 ACL -
禁用 ACL（仅限可信环境）：执行 sudo setfacl -b /host/path 移除所有 ACL 条目，回归传统 rwx 权限模型，再用
chmod和chown控制
避免 root 依赖：更安全的长期解法
生产环境不建议让容器内 root 操作敏感挂载目录。应转向 UID 对齐模式：
- 在宿主机上将目录属主设为目标 UID（如 1001）：sudo chown -R 1001:1001 /host/path
- Dockerfile 中创建同 UID 用户：
RUN useradd -u 1001 -m appuser，并USER appuser - 启动时强制指定：docker run -u 1001:1001 -v /host/path:/container/path ...
ACL 的本质是扩展权限控制，它不会因容器而失效，也不会被 Docker 特殊处理。解决的关键不是“在容器里改”，而是让宿主机的权限策略明确覆盖到容器所用的 UID/GID。
