核心是UID/GID不匹配，Linux按数字ID判定权限；需先用ls -ld和docker run ... id确认宿主机目录与容器进程的UID/GID，再通过chown调整宿主机目录属主或docker run --user显式指定一致UID/GID。
核心是 uid/gid 不匹配，不是目录“不够开放”。linux 按数字 id 判定权限，容器进程用的 uid 在宿主机上没对应属主或权限，哪怕目录设成 755 也会报 permission denied。
先确认两边是谁在操作
不猜，直接查：
-
宿主机目录归属：运行
ls -ld /host/path，记下 UID 和 GID（比如1001:1001） -
容器内实际用户：用测试镜像跑一次，
docker run -v /host/path:/test -it --rm alpine id，看输出的uid和gid - 镜像默认用户：很多官方镜像（如 nginx、node、mysql）已预设非 root 用户，UID 常见为 101、999、1001，不是 0
让 UID/GID 对齐（推荐首选）
一劳永逸，避免权限漂移：
-
改宿主机目录属主：用
sudo chown -R 1001:1001 /host/path（把 1001 换成你确认的 UID） -
启动时指定用户：用
docker run -v /host/path:/container/path --user 1001:1001 image:tag -
Dockerfile 中预设用户：构建时创建同 UID 的用户，再
USER 1001，确保镜像自带身份
处理 SELinux 或 AppArmor 干扰
尤其在 CentOS/RHEL 或部分 Ubuntu 上，安全模块会静默拦截：
-
临时验证：执行
sudo setenforce 0后重试容器启动；若成功，就是它在拦 -
生产环境修复：给目录打标签，例如
sudo semanage fcontext -a -t container_file_t "/host/path(/.*)?"，再sudo restorecon -Rv /host/path -
运行时加挂载标签：用
-v /host/path:/container/path:Z（SELinux 环境）或:z（共享上下文）
换种挂载方式更省心
bind mount 容易打架，命名卷由 Docker 自动管理权限：
- 创建命名卷：
docker volume create mydata - 挂载使用：
docker run -v mydata:/container/path image:tag - 优势：不用操心宿主机权限、UID 对齐、SELinux 标签；适合开发、CI/CD、日志缓存等场景
