根本原因是宿主机目录uid/gid与容器内进程不匹配；需先用ls -ld和id确认双方数字id，再通过chgrp/chmod调整宿主机目录属组权限，或启动时用--user显式指定一致uid/gid，nfs挂载还需透传uid/gid参数。
容器挂载后写不了，不是Docker故意设障，而是Linux文件权限模型在起作用——宿主机目录的UID/GID和容器内进程不一致，系统内核自然拒绝访问。
先查清楚谁在用、谁拥有
别急着改权限，先确认两边身份是否对得上：
- 在宿主机运行 ls -ld /host/path，看目录属主 UID 和属组 GID
- 进容器执行 id，确认实际运行进程的 uid/gid（注意：不是镜像里写的用户名，是数字ID）
- 如果两者不匹配，比如宿主机目录属组是 1001，而容器里进程 gid 是 1002，写入就会被拒
优先调宿主机目录，而不是容器用户
最稳的做法是让宿主机目录“迁就”容器进程，而非反过来：
- 用 sudo chgrp -R 1001 /host/path 把目录属组改成容器需要的 GID
- 再补一句 sudo chmod g+rwX /host/path，确保组有读写执行权（X 表示对目录加 x，对文件按需加）
- 避免直接 chown -R 1001:1001 改 UID——宿主机未必有这个用户，还可能影响其他服务
启动时显式指定用户，别信镜像默认
很多镜像（如 nginx:alpine）内置了 www-data 或 nginx 用户，但这些名字在宿主机并不存在，只靠名字容易误判：
- 启动命令里加 --user 1001:1001，强制容器以确定 UID/GID 运行
- Dockerfile 中也写明 USER 1001:1001，防止运行时被覆盖
- 某些程序（如 Nginx）还需额外配置 user 1001; 才真正降权，光靠 --user 不够
SELinux 环境才需要 :z 标签
:z 和 :Z 不是万能钥匙，只在 SELinux enforcing 模式下生效：
- 先运行 sestatus，输出为 disabled 或 permissive 就不用加 :z
- 真在 enforcing 模式（如 RHEL/CentOS 7），挂载时加 -v /host:/cont:z，Docker 会自动打上 svirt_sandbox_file_t 标签
- :Z 更严格，适合私有卷；多个容器共用一个目录时误用 :Z 反而会互相锁死
NFS 挂载点要透传 uid/gid
如果 /host/path 实际是 NFS 挂载的远程目录，问题常出在客户端没传参数：
- 检查 /etc/fstab 或 mount 命令，确认挂载选项含 uid=1001,gid=1001
- 否则 NFS 默认用 nobody:nogroup，容器里即使 uid=1001 也拿不到写权限
- 临时修复可用 sudo mount -o remount,uid=1001,gid=1001 /mnt/nfs
