docker volume挂载失败通常源于宿主机路径不存在、权限不匹配、selinux/apparmor阻断、nfs等远程存储连通异常或命名卷与绑定挂载混淆；需依次排查路径创建与权限（如mkdir -p /data/app && chmod 755）、uid/gid对齐、添加:z/:z标签、验证nfs服务及showmount、区分-v绝对路径（绑定挂载）与命名卷。
Volume 挂载失败，通常不是 Docker 自身“挂不上”，而是路径、权限、安全策略或后端存储连通性出了问题。直接查日志看到 “no such file or directory” 或 “permission denied”，别急着重装 Docker，先按这几类常见原因逐项排查。
宿主机路径不存在或权限不对
这是最常踩的坑。Docker 在绑定挂载（-v /host/path:/container/path）时，若宿主机路径不存在，部分版本会自动创建目录，但父目录若无执行（x）权限，就会失败；更多时候是容器内进程 UID 无法读写宿主机目录。
- 运行前手动创建并赋权：
sudo mkdir -p /data/app && sudo chmod 755 /data/app - 确认容器内用户能访问：比如容器用 UID 1001 启动，宿主机目录属主就得是 1001 或所在组有读写权限
- 避免盲目
chmod 777，尤其在生产环境；更稳妥的是用--user $(id -u):$(id -g)对齐 UID/GID
SELinux 或 AppArmor 阻断访问
在 CentOS/RHEL/Fedora 等默认启用 SELinux 的系统上，即使路径存在、权限正确，也会因安全上下文不匹配被静默拒绝。典型表现是容器能启动，但挂载点下为空或报 Permission denied。
- 临时验证：运行前执行
sudo setenforce 0，再启动容器看是否恢复 - 永久修复：挂载时加
:Z（多容器共享）或:z（单容器专用），如-v /data/app:/app:data:Z，让 SELinux 自动打标 - AppArmor 用户可检查
/etc/apparmor.d/下是否有针对 Docker 的配置限制了路径访问
NFS/CIFS 等远程存储连通异常
挂载的是 NFS 共享？那“挂载失败”大概率不是 Docker 的错，而是网络或服务本身没通。容器切到 host 网络后突然挂不上，往往因为 DNS 解析失败、防火墙拦了 RPC 端口（如 111、2049）、或 NFS 服务未导出该路径。
- 在宿主机上测试：
showmount -e nfs-server-ip看能否列出共享目录 - 确认
rpcbind和nfs-server服务已启动，且/etc/exports配置生效（exportfs -a） - Docker 创建 NFS 卷时，务必用
--opt o=addr=...,nolock,soft,rw，其中soft可防挂起，nolock避免 NFS 锁冲突
命名卷与绑定挂载混淆误用
把 -v myvol:/data 当成绑定挂载用，结果发现宿主机根本找不到 myvol 对应的目录——因为它压根不在你预期的文件系统路径下，而是在 /var/lib/docker/volumes/ 里由 Docker 管理。
- 想用宿主机真实路径，必须用绝对路径：
-v /home/user/data:/app/data - 想用 Docker 托管的持久化存储，就用命名卷：
docker volume create mydata && docker run -v mydata:/app/data nginx - 查清当前挂载状态：
docker inspect 容器名 | jq '.[0].Mounts'或findmnt -T /目标路径
