核心是让容器进程uid/gid与宿主机挂载目录所有者数字id一致；需先用ls -ld和id实测确认，再通过chown调整宿主机目录属主或docker run --user显式指定一致uid/gid，selinux干扰时加:z标签或调整上下文。
核心是让容器进程的 UID/GID 和宿主机挂载目录的实际所有者对得上——Linux 只认数字 ID，不认用户名。改 chmod 777 或在容器里 chown 多数无效，真正有效的动作必须落在启动前或宿主机侧。
先确认两边 UID/GID 是否一致
这是排查起点，不是猜，而是实测：
- 在宿主机运行 ls -ld /host/path，看第三、四列的数字（比如
drwxr-xr-x 2 1001 1001），这就是目录真实归属 - 进容器执行 id，记录 uid 和 gid（比如
uid=1000 gid=1000） - 对比两个数字：不一致 → 直接导致 Permission denied；一致但仍有问题 → 往下查 SELinux 或 NFS 配置
宿主机预设权限 + 容器显式指定用户
这是最稳定、推荐用于生产环境的做法：
- 在宿主机上把目录属主设为目标 UID/GID：sudo chown -R 1001:1001 /host/path
- 设合理权限（读写需求强时用 775，一般用 755）：sudo chmod -R 755 /host/path
- 启动容器时明确指定用户：docker run -u 1001:1001 -v /host/path:/container/path image
- 用 docker-compose？在 service 下加：user: "1001:1001"
应对 NFS 挂载的特殊处理
NFS 不只是客户端的事，服务端配置决定权限能否落地：
- 检查 NFS 服务端 /etc/exports 是否启用了
root_squash（默认开启），它会把容器 root 映射成 nobody - 安全做法：服务端保持
root_squash，但加上anonuid=1001,anongid=1001，把匿名访问映射到业务用户 - 改完执行 exportfs -ra，再在客户端重新挂载
- 切勿轻易启用
no_root_squash，除非网络完全可信且有强隔离
SELinux 干扰时的快速适配
即使 UID 对齐、权限开放，SELinux 仍可能拦截：
- 运行 getenforce 查状态；若为
Enforcing，临时验证可执行 sudo setenforce 0 - 长期方案：挂载时加 SELinux 标签，:z（共享上下文）或 :Z（多实例隔离）
- 例如：docker run -v /host/path:/container/path:Z image
- 不建议长期关闭 SELinux，应生成定制策略或调整文件上下文类型
