外接硬盘断开导致容器退出或启动失败，本质是 docker 尝试访问已失效的挂载点（如 wsl2 中 stale 的 /mnt/d），触发内核拒绝；应通过 wsl --shutdown 重置、umount/mount 恢复 drvfs 挂载，或改用 wsl2 本地路径+命名卷规避。
外接硬盘断开后容器直接退出或启动失败
容器因挂载的外接硬盘（如 NTFS 格式的 USB 硬盘、移动 SSD）突然拔出而报错退出，常见现象是 docker start 失败、docker run 卡住、或日志里反复出现 no such file or directory / device or resource busy。这不是 Docker 本身崩溃，而是它在尝试访问一个已消失的挂载点时被内核拒绝。Windows 下尤其明显——Docker Desktop 通过 WSL2 访问 Windows 文件系统，而外接盘拔出后，WSL2 内部对 /mnt/d（假设盘符是 D:\）的挂载会残留或失效，但 Docker 引擎仍试图读取该路径元数据。
关键判断点：docker ps -a 查看容器状态是否为 Created 或 Exited (1)；docker logs <container_id></container_id> 基本为空或只输出启动前几行；docker inspect <container_id></container_id> 的 Mounts 字段里能看到宿主机路径（如 "Source": "/mnt/d/mydata"），但该路径在 WSL2 里已不可达。
- 不要强行
docker start—— 它会重试挂载，失败后立即退出，且可能卡住守护进程 - 先确认外接盘是否真的重连：在 Windows 资源管理器里看盘符是否恢复；在 PowerShell 里执行
wsl -e ls /mnt/d，若报错No such file or directory，说明 WSL2 还没重新识别该盘 - 如果盘已重连但 WSL2 未同步，执行
wsl --shutdown再重启 Docker Desktop，强制刷新所有挂载点映射
WSL2 中 /mnt/ 盘符挂载状态异常
Docker Desktop 依赖 WSL2 将 Windows 盘符自动挂载到 /mnt/c、/mnt/d 等路径。外接硬盘拔出后，WSL2 不会自动卸载对应路径，而是让该目录变成“stale mount”（陈旧挂载）。此时 ls /mnt/d 可能卡住、超时，或返回 Transport endpoint is not connected。Docker 引擎在初始化容器挂载时，会调用 stat() 检查源路径，遇到这类状态就直接报错，不给重试机会。
验证方式：wsl -e mount | grep /mnt/d —— 若显示 type drvfs (rw,noatime,uid=0,gid=0,iocharset=utf8,case=off) 但后续 ls 失败，基本就是 stale mount。
- 临时修复：在 WSL2 终端中执行
sudo umount /mnt/d，再执行sudo mkdir -p /mnt/d && sudo mount -t drvfs d: /mnt/d（注意大小写和冒号） - 永久规避：避免在
-v中直接挂载外接盘根路径（如-v /mnt/d/data:/app/data）；改用 WSL2 内部路径（如/home/user/data）做中转，或把数据先 rsync 到 WSL2 的 ext4 文件系统上再挂载 - 注意：
drvfs挂载不支持bind类型的嵌套挂载，所以不要在/mnt/d下再建子挂载点并期望 Docker 能穿透识别
compose.yml 中挂载外接盘路径导致服务无法 up
使用 docker-compose up 时，若 volumes: 下写了类似 - D:/data:/app/data（Windows 风格路径）或 - /mnt/d/data:/app/data（WSL2 风格路径），一旦盘断开，up 会直接失败并提示 invalid mount config for type "bind" 或 failed to create shim task: OCI runtime create failed。这是因为 Compose 在构建容器前就尝试解析宿主机路径有效性，而 stale mount 或断连状态会让路径检查失败。
- 路径必须是绝对路径，且不能含环境变量（如
${DATA_PATH}）——Compose 不会在运行时展开它们来校验存在性 - 开发阶段建议加一层抽象：在
docker-compose.yml里用命名卷（named volumes）替代 host bind，再通过driver_opts或初始化脚本把数据从外接盘同步进来，解耦容器生命周期与硬件连接状态 - 若必须 bind mount，可在启动前加 shell 检查：
if [ ! -d "/mnt/d/data" ]; then echo "D: drive missing"; exit 1; fi，放在entrypoint或启动 wrapper 脚本里
如何让容器对硬盘热插拔有基本容忍度
完全避免报错不现实，但可以降低影响范围。核心思路是：不让挂载失败阻塞容器主进程启动，把路径可用性检查推迟到业务代码里，而非 Docker 初始化阶段。
- 不要在
Dockerfile中用VOLUME声明外接盘路径——它会强制绑定，且无法跳过 - 把挂载点设为非必需：例如挂载到
/app/optional-data，应用启动时不校验该目录是否存在，只在实际读写时才处理ENOENT或EIO - 在容器内用
inotifywait监听/mnt/d目录事件（需提前安装 inotify-tools），检测到ATTRIB或MOVED_TO后再触发数据加载逻辑 - 最稳妥的做法：外接盘只用于冷备份或批量导入，日常开发/测试全部走 WSL2 本地 ext4 分区（如
/home/user/project/data），彻底避开 drvfs 的稳定性问题
真正麻烦的不是拔盘那一刻，而是你忘了它曾被拔过——stale mount 会一直留在 WSL2 里，直到手动清理或重启。下次启动容器时它才突然爆发，错误信息却和原始操作毫无关联。这点最容易被忽略。
