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 必须用绝对路径，否则报错或行为异常