核心原因是宿主机与容器uid/gid不匹配，linux按数字id判定权限；需先用ls -ld和id确认双方uid/gid，再通过chown调整宿主机目录属主或docker run --user显式指定一致uid/gid。
容器挂载目录读写报错，核心是宿主机与容器之间用户身份不匹配——Linux 看 UID/GID 数字，不看用户名。只要容器进程用的 UID 在宿主机上没对应权限，哪怕目录权限设成 755，照样“Permission denied”。
确认挂载目录归属和容器运行用户
先搞清两边是谁在操作：
- 查宿主机目录归属：
ls -ld /path/to/mounted/dir，记下 UID 和 GID（比如 1001:1001） - 查容器内实际运行用户：
docker run -v /path/to/dir:/test -it --rm alpine id，看输出的 uid/gid - 如果镜像指定了非 root 用户（如 vllm、mysql、nginx），注意它默认用的 UID 可能不是 0，常见有 1001、999、101 等
统一 UID/GID 是最稳妥的做法
让容器进程 UID 和宿主机目录所有者 UID 一致，一劳永逸：
- 修改宿主机目录归属：
sudo chown -R 1001:1001 /path/to/mounted/dir（把 1001 换成你确认的 UID） - 补上必要权限：
sudo chmod -R 755 /path/to/mounted/dir（组和其他用户需有读+执行权，否则某些程序会失败） - 启动容器时显式指定用户：
docker run -v /host/data:/container/data --user 1001:1001 image:tag
SELinux 或 AppArmor 干扰时的处理
尤其在 CentOS/RHEL 系统上，即使 UID 对齐也可能被拦截：
- 临时验证是否 SELinux 导致：
sudo setenforce 0，再试启动；若成功，说明是它 - 永久修复：给挂载路径打标签，例如
sudo semanage fcontext -a -t svirt_sandbox_file_t "/path/to/dir(/.*)?"，然后sudo restorecon -Rv /path/to/dir - 或启动时加
:Z标签（仅限 SELinux 启用环境）：docker run -v /host/dir:/container/dir:Z image
避免用 root 写，也别盲目 chmod 777
生产环境不推荐无差别开放权限：
-
chmod 777仅适合本地快速验证，上线必须收敛权限 - 优先用 named volume 替代 bind mount：Docker 自动管理权限，
docker volume create mydata，再--mount source=mydata,target=/data - 确保当前用户已加入 docker 组：
sudo usermod -aG docker $USER，避免因 docker daemon 权限间接引发问题
