Docker容器启动时不主动检查挂载点就绪性，而是在MNT namespace初始化时执行挂载；失败则中止创建或导致运行时问题，需启动后用docker inspect、findmnt等手动验证。
容器启动时，Docker 并不会主动“检查”挂载点是否就绪或可用，而是按配置执行挂载动作；若挂载失败，容器可能启动失败或挂载点在容器内不可见——这取决于挂载类型和错误性质。
挂载动作发生在容器命名空间初始化阶段
当 docker run 执行时，Docker daemon 会调用 containerd 创建容器，并在 Linux namespace（特别是 MNT namespace）初始化过程中完成挂载操作。此时：
- bind mount：宿主机路径必须存在（否则报
No such file or directory），但内容可为空；目录权限需允许 Docker 进程访问 - named volume：Docker 自动创建对应目录（如
/var/lib/docker/volumes/xxx/_data），无需预建 - NFS 或其他远程文件系统：挂载动作由 kernel 的
mount系统调用触发，依赖宿主机已正确配置并可达；失败通常表现为容器卡在 starting 状态或立即退出
挂载是否成功，容器本身不校验，只反映结果
Docker 不在容器启动流程中插入“健康检查式”的挂载验证逻辑。它依赖内核返回的挂载结果：
- 若
mount(2)系统调用失败（如路径不存在、权限拒绝、NFS 超时），Docker 报错并中止容器创建，例如：invalid mount config for type "bind": bind source path does not exist - 若挂载成功但目录为空或权限不足（如 NFS 的
root_squash导致 root 写入被降权），容器仍会启动，但应用读写时才暴露问题 - overlay2 层叠结构不影响挂载点可见性，但会影响文件覆盖行为：上层（upperdir）对挂载目录的修改可能被白名单机制屏蔽，导致写入静默失败
如何确认挂载是否生效
启动后需主动验证，而非依赖启动过程自动保障：
- 查容器挂载配置：
docker inspect 容器名 | jq '.[0].Mounts'，确认Source、Destination、Type和Mode正确 - 进容器验证可见性：
docker exec -it 容器名 ls -ld /挂载路径，观察是否存在、属主/权限是否符合预期 - 检查实际挂载状态：
docker exec -it 容器名 findmnt -T /挂载路径或mount | grep 挂载路径 - 对 NFS 等网络存储，还需在宿主机侧确认：
mount | grep nfs、showmount -e NFS服务器、rpcinfo -p NFS服务器
常见挂载失败的隐性诱因
有些问题不会阻断容器启动，却让挂载“形同虚设”：
- 宿主机目录被 bind mount 覆盖：如镜像内已有
/app目录，而你挂载-v /host/app:/app，则镜像中该路径下原有文件全部不可见 - SELinux/AppArmor 限制：即使
ls -ld显示权限正常，安全模块也可能拦截 mount 或 open 系统调用，临时禁用可快速定位（setenforce 0） - 用户 ID 映射冲突：容器以 UID 0 启动，挂载到 NFS 时被
root_squash映射为nfsnobody，导致写入权限丢失 - 路径使用相对路径或未加前导斜杠：Docker 要求 bind mount 必须用绝对路径，否则报错或行为异常
