数据卷权限不足需查uid/gid匹配、对齐运行用户、调宿主机权限或selinux策略：先用id和ls -ld确认数字id是否一致，再通过-u参数对齐，或chown/chmod调整目录权限，最后检查selinux/apparmor拦截。
数据卷权限不足报错，核心是容器进程 UID/GID 与宿主机目录属主不匹配，或安全模块拦截。解决不靠猜，靠查、对、调三步走。
确认容器 UID 和宿主机目录属主是否一致
别看用户名，只看数字 UID：
- 进容器执行 id -u 和 id -g，记下两个数字（比如 1001）
- 在宿主机执行 ls -ld /path/on/host，看第三列（属主 UID）和第四列（属组 GID）
- 若两者不等（如容器用 1001，目录属 1002），写操作大概率失败
让容器以宿主机目录属主身份运行（推荐首选）
不用改镜像、不加特权，直接对齐 UID/GID：
- 动态获取：docker run -u $(stat -c "%u:%g" /path/on/host) -v /path/on/host:/container/path image
- 手动指定：docker run -u 1001:1001 -v /host/data:/app/data image
- 适用于 nginx、redis、node 等多数官方镜像，只要该 UID 在容器内有基本 shell 环境即可
调整宿主机目录权限（适用闭源或固定用户场景）
当无法控制容器 UID 时，反向适配宿主机：
- 改属主：sudo chown -R 1001:1001 /path/on/host（1001 是容器内实际 UID）
- 补权限：sudo chmod -R g+rwX,o+rx /path/on/host（X 只对目录和已有执行位的文件生效）
- 避免无脑 chmod 777，尤其生产环境；o+rx 已足够让“其他用户”读取和进入目录
检查 SELinux 或 AppArmor 干预（CentOS/RHEL/Ubuntu 常见）
即使 UID 对、权限足，仍报 Operation not permitted，八成是安全模块在拦：
- 确认状态：getenforce（SELinux）或 aa-status（AppArmor）
- 临时验证：挂载时加 :z（SELinux 共享卷）或 :Z（私有卷）
- 生产环境建议配 SELinux 策略，而非关闭或加 --privileged
