大多数情况下，这是因为容器内进程的用户 ID 与宿主机挂载目录的所有者不匹配，调整宿主机目录权限或指定容器运行用户即可解决。

典型报错日志

在应用日志或 docker logs 中，通常会看到类似以下的错误信息：

ERROR: failed to create directory "/app/data": permission denied
EACCES: permission denied, open '/app/data/config.json'

这表明容器内的进程没有权限在挂载点写入数据。

核心原因

Docker 容器默认以 root 用户运行，但挂载的宿主机目录可能属于普通用户。Linux 内核在进行文件访问检查时，会对比进程的有效用户 ID（UID）和文件的所有者 ID。如果容器内进程 UID 为 0（root），而宿主机目录属于 UID 1000 且权限 restrictive，或者反之，就会触发 Permission denied。

此外，SELinux 或 AppArmor 等安全模块也可能拦截挂载卷的访问，即使文件权限看似正确。

解决方案

方案一：指定容器运行用户（生产环境推荐）

最安全的做法是让容器进程使用与宿主机目录所有者相同的 UID/GID 运行。

docker run `--user` 1000:1000 -v /path/to/host/data:/app/data image_name

注意：`--user` 参数后直接跟数字，不要加多余符号。

方案二：修改宿主机目录归属

如果无法修改容器启动参数，可以修改宿主机目录的所有者以匹配容器内用户。

sudo chown -R 1000:1000 /path/to/host/data

先通过 docker exec -it <container_id> id 确认容器内 UID/GID。

方案三：docker-compose 完整配置示例

version: '3'
services:
  app:
    image: image_name
    user: "1000:1000"
    volumes:
      - ./data:/app/data

SELinux 特殊处理

在 CentOS/RHEL/Fedora 上，即使权限正确也可能被 SELinux 拦截。推荐使用 Docker 自带的挂载标签。

# 共享内容使用 :z，私有内容使用 :Z
docker run -v /path/to/host/data:/app/data:z image_name

避免直接使用 chcon 修改系统安全上下文，除非你明确知道自己在做什么。

验证方法

在容器内创建一个测试文件，然后检查宿主机上该文件的归属。

# 容器内
docker exec -it <container_id> touch /app/data/testfile

# 宿主机
ls -l /path/to/host/data/testfile

如果文件成功创建且没有报错，说明权限问题已解决。

安全与特殊场景

• 避免 chmod 777：不要使用 chmod 777 开放所有权限，这会带来严重安全风险。仅在临时调试时使用，并尽快恢复。
• Rootless Docker：如果你使用的是 Rootless 模式，容器内的 root 实际映射为宿主机普通用户，权限逻辑会有所不同，需检查 user namespace 映射。
• 命名卷 vs 绑定挂载：Docker 管理的命名卷（Named Volumes）通常由 Docker 守护进程控制权限，较少出现此类问题；绑定挂载（Bind Mounts）直接依赖宿主机文件系统权限，更容易出错。