宿主机路径存在性与基础权限检查是排查起点，90%挂载失败卡在此步；需确认目录存在、可读写、有执行权限，并对齐容器与宿主机uid/gid，避免仅依赖chmod或:ro治标不治本。
卷权限问题不是配置写错那么简单，而是宿主机、容器用户、挂载模式三者之间uid/gid、目录所有权、读写标志共同作用的结果。搞不清底层映射逻辑，光改chmod或加:ro往往治标不治本。
宿主机路径存在性与基础权限检查
这是所有排查的起点，90%的“挂载失败”其实卡在这一步。
- 确认宿主机目标目录真实存在：
ls -ld /host/data，若提示No such file，需先创建：mkdir -p /host/data - 检查目录是否可被当前用户访问：
test -r /host/data && echo "readable" || echo "not readable" - 若使用非root用户运行Docker，确保该用户对目录有执行（
x）权限——Linux中进入目录需要x，不只是r
容器内用户UID/GID与宿主机目录所有权对齐
容器进程以某个UID运行，而宿主机目录归另一个UID所有，权限拒绝就必然发生。
- 查容器实际运行用户：
docker inspect <container> | jq '.[0].Config.User'</container>，若为空则默认为root - 查宿主机目录归属：
ls -ld /host/data，关注第三、四列（如1001 1001） - 启动时强制匹配UID：
docker run --user $(id -u):$(id -g) -v /host/data:/data myapp - 镜像构建阶段固化UID更稳妥：
RUN addgroup -g 1001 appgrp && adduser -D -u 1001 -G appgrp appuser，再USER appuser
只读（:ro）挂载引发的隐性崩溃
看似安全的:ro常让服务静默退出——应用没报错，只是日志不写、缓存不建、PID文件无法生成。
- 区分用途挂载：配置目录用
:ro，日志/临时/数据目录必须:rw（显式写出更清晰） - 验证只读生效：
docker exec -it <container> sh -c "echo test > /data/test.txt" 2>&1</container>，应返回Permission denied - 若应用必须写某路径但你又想保护原始数据，可用
tmpfs临时挂载替代：--tmpfs /app/cache:rw,size=64m
SELinux/AppArmor等强制访问控制干扰
在CentOS/RHEL或启用了安全模块的系统上，即使文件权限全开，也可能因策略拦截挂载。
- 快速验证是否为SELinux导致：
getenforce返回Enforcing时需进一步检查 - 临时放宽策略测试：
setenforce 0，若挂载恢复则确认是SELinux问题 - 持久化修复：为挂载目录打上正确上下文，例如：
chcon -Rt svirt_sandbox_file_t /host/data - 或在
docker run中添加--security-opt label=disable（仅限测试环境）
