根本原因是UID/GID映射不一致、目录权限不足或SELinux/AppArmor干预；需先用id -u/-g和ls -ld确认容器进程UID与宿主机目录属主数字是否一致，再通过--user指定、chown调整或安全模块标记解决。
容器存储卷挂载权限不足，本质是宿主机与容器间用户身份（UID/GID）不匹配或安全策略拦截，不是单纯“改个权限”就能解决。关键在定位差异、对齐身份、绕过限制。
查清 UID/GID 是否匹配
权限拒绝最常见原因是容器进程的 UID/GID 和宿主机文件所有者不一致。Linux 不认用户名，只认数字 ID。
- 在宿主机上运行：ls -ln /path/on/host，看目标目录或文件的 UID/GID（第三、四列）
- 进容器查运行用户：docker exec -it 容器名 id，对比 uid/gid 是否一致
- 若不一致，比如宿主机是 1001:1001，容器内是 1000:1000，那写操作必然被拒
确认挂载路径和父目录权限是否到位
即使目标目录权限宽松，它的上级目录若缺少执行（x）权限，也会导致“Permission denied”——因为 Linux 需要逐级进入，缺一不可。
- 用 namei -l /path/on/host 查看完整路径每级的权限和所有者
- 确保从根目录到目标目录，每一级对容器用户（UID）都有 x 权限（对目录而言，x 表示可进入）
- 特别注意 QNAP 等 NAS 设备，默认共享路径如 /share/container，需确认 docker 用户组有读写执行权限
排查 SELinux 或 AppArmor 干预
即便 UID/GID 对得上、目录权限也够，安全模块仍可能静默拦截访问，错误表现一样，但日志里留痕。
- 检查 SELinux 状态：getenforce，若为 Enforcing，尝试临时设为 Permissive 测试是否恢复
- 查看审计日志：sudo ausearch -m avc -ts recent | tail -10，找 denied 条目
- AppArmor 可用 aa-status 查看是否启用，相关容器 profile 是否限制了 mount 或 file access
验证 NFS 挂载特有的 UID 映射问题
挂载 NFS 卷时，服务端导出配置（如 /etc/exports）常含 no_root_squash 或 all_squash，会强制重映射 UID，导致容器用户失效。
- 登录 NFS 服务器，检查导出选项：cat /etc/exports，重点关注 anonuid、anongid、root_squash
- 若使用 all_squash，所有客户端用户都会被映射成指定 anonuid，此时容器必须用该 UID 启动：docker run --user 65534:65534 ...
- NFSv4 推荐启用 sec=sys 或 krb5，避免 v3 的 UID 猜测式映射
