核心是让容器进程UID/GID与宿主机目录属主一致：先用ls -ld和docker run ... id确认双方数字身份，再通过--user显式指定匹配UID/GID，或调整宿主机目录chown，SELinux环境加:z挂载标签。
开发环境隔离下解决容器挂载权限拒绝问题，核心是让容器进程身份与宿主机目录权限对齐，而不是绕过安全机制。关键不在“开权限”，而在“认对人”——linux 只认 uid/gid 数字，不认用户名。
查清两边是谁：宿主机目录属主 vs 容器运行用户
先确认实际数字身份，避免被用户名误导：
- 查宿主机目录归属：ls -ld /path/to/mount，记下输出中的 UID 和 GID（例如 1001 1001）
- 查容器内真实用户：docker run -v /path/to/mount:/test -it --rm alpine id，看 uid/gid 输出（不是镜像名或 Dockerfile 里写的 USER nginx）
- 若用 docker-compose，可在 service 下加 command: id 启动后立刻查看
推荐做法：启动时用 --user 显式指定 UID/GID
这是开发环境最轻量、可逆、无需改镜像的解法：
- 直接匹配宿主机当前用户：docker run -v /host/data:/app/data --user $(id -u):$(id -g) myapp
- 固定 ID 更稳妥（尤其团队协作）：docker run -v /host/data:/app/data --user 1001:1001 myapp
- docker-compose.yml 中写：user: "1001:1001"，放在对应 service 下
备选方案：调整宿主机目录归属（适合静态资源或共享目录）
当无法控制容器用户（如第三方镜像），且你有宿主机管理权时可用：
- 把目录属主改成容器预期 UID：sudo chown -R 1001:1001 /host/data
- 补上必要读执行权限（尤其 Nginx/Node.js 静态服务）：sudo chmod -R a+rX /host/data（a+rX 表示所有用户可读、目录可执行，比 755 更安全）
- 避免 chmod 777 —— 它在 SELinux 环境下常被拦截，且违反最小权限原则
别忘了 SELinux 或 AppArmor 的静默拦截
CentOS/RHEL 或 Ubuntu 上，即使 UID 对齐也可能失败：
- 临时验证是否是它导致：sudo setenforce 0，再试启动；成功则说明需处理上下文
- 开发环境快速修复：docker run -v /host/data:/app/data:z myapp（小写 z 表示共享上下文）
- 或给目录打标签：sudo chcon -Rt container_file_t /host/data
