直接原因是容器内进程UID/GID与宿主机挂载目录属主不匹配；解决核心是数值对齐——先用ls -ld和id确认双方UID/GID，再通过--user、Dockerfile建用户或docker-compose.yml的user字段统一映射。
直接原因是容器内进程的 UID/GID 与宿主机挂载目录的属主不匹配，系统按数字 ID 判定权限，而非用户名。解决核心是让访问者（容器用户）和被访问者（目录属主）在 UID/GID 层面对得上。
确认当前挂载点的实际权限归属
先在宿主机上查清目录所有者和权限：
- 运行 ls -ld /path/on/host 查看目录属主 UID/GID 和权限位
- 进入容器执行 id，确认应用进程实际以哪个 UID/GID 运行
- 对比两者数字是否一致——不一致就是权限拒绝的直接原因
统一 UID/GID 是最稳妥的解法
避免依赖宽松权限或禁用安全机制，优先对齐身份：
- 若宿主机目录属主是 devuser (UID 1001)，启动容器时显式指定：
docker run --user 1001:1001 -v /host/data:/app/data myimage - 在 Dockerfile 中提前创建同 UID 用户：
RUN groupadd -g 1001 appgroup && useradd -u 1001 -g appgroup appuser - 使用 Compose 时，在 service 下加：
user: "1001:1001"
配合 NFS 挂载需额外注意服务端配置
NFS 权限还受服务端导出选项约束，不能只调客户端：
- 检查 NFS 服务器 /etc/exports 是否启用了 root_squash（默认开启），它会把容器 root 映射成 nobody
- 如需容器 root 写入，且网络可信，可临时改用：
/data 192.168.1.0/24(rw,sync,no_root_squash)，再 exportfs -ra - 更安全的做法是：NFS 目录属主设为应用 UID（如 1001），服务端保持 root_squash，容器也以 UID 1001 启动
SELinux 或 AppArmor 阻断时的快速验证
权限看似正确但仍报 “Operation not permitted”，很可能是安全模块拦截：
- 运行 getenforce 查 SELinux 状态；若为 Enforcing，临时设为 permissive：
sudo setenforce 0 测试是否恢复 - 挂载时加 :Z（多实例隔离）或 :z（共享上下文）标签：
docker run -v /host/path:/container/path:Z myimage - 生产环境不建议长期关闭 SELinux，应生成对应策略或调整上下文类型
