Docker 使用 overlay2 存储驱动时，偶尔会出现容器启动失败、镜像层无法挂载、Docker 服务无法启动等问题，日志中常见 “failed to mount overlay”“invalid argument”“no such file or directory” 或 “device or resource busy”。🔧 这类故障往往与底层文件系统、磁盘空间、内核能力、目录损坏或残留挂载有关。下面提供一套从信息收集到安全修复的排查流程。
一、先了解 overlay2 的工作方式
overlay2 基于 Linux OverlayFS，将镜像只读层与容器可写层组合成统一视图。Docker 数据目录通常位于 /var/lib/docker，其中 overlay2 子目录保存层数据和关联信息。每个活动层通常涉及 lowerdir、upperdir、workdir 与 merged 等目录，任何一项路径缺失、权限异常或挂载关系不完整，都可能导致容器无法启动。
需要注意的是，容器的可写层适合临时数据，不适合承担数据库等高频持久化写入。重要业务数据应优先放入 Docker volume 或可靠的外部存储，避免 overlay2 层损坏时扩大影响。相关原理可参考 Docker OverlayFS 官方文档。
二、确认实际故障范围
不要看到挂载报错就立即删除 overlay2 目录。应先判断问题影响单个容器、部分镜像，还是整个 Docker 服务。可依次执行以下检查：
- docker info：确认 Storage Driver、Backing Filesystem 和 Supports d_type 等信息。
- docker ps -a：观察是否只有特定容器无法启动。
- systemctl status docker：查看服务状态和最近的启动错误。
- journalctl -u docker --no-pager -n 200：获取较完整的守护进程日志。
- dmesg -T：检查内核是否报告 I/O 错误、OverlayFS 错误或文件系统异常。
📌 排查时应保存完整报错，而不是只截取 “mount failed” 一行。错误前后的层 ID、路径和内核提示，通常才是定位根因的关键。
三、检查磁盘空间与 inode
磁盘容量不足是最常见的诱因之一，但仅执行 df -h 还不够。即使剩余容量充足，inode 耗尽也会导致 Docker 无法创建目录、临时文件或层链接。
执行 df -h 检查容量，执行 df -i 检查 inode，执行 du -xh --max-depth=1 /var/lib/docker 检查 Docker 各目录占用。
如果发现空间不足，可先清理无用日志、构建缓存和已确认不再使用的对象。生产环境不要直接执行破坏范围不明确的全量清理命令。建议先使用 docker system df 查看占用，再按镜像、容器、构建缓存分别处理。🧹
四、核对底层文件系统兼容性
overlay2 依赖底层文件系统和内核功能。若 Docker 数据目录位于 XFS 上，应检查 d_type 支持，通常可通过 xfs_info 查看 ftype 是否为 1。Docker 官方说明，XFS 作为 overlay2 后端时需要启用 d_type。若文件系统格式本身不满足条件，仅修改 daemon.json 通常无法解决问题。
同时执行 findmnt /var/lib/docker，确认 Docker 根目录实际落在哪个设备和文件系统上。若该目录位于 NFS、某些特殊网络文件系统、嵌套 OverlayFS 或受限制的虚拟化环境中，可能无法正常创建 overlay 挂载。此时应将 Docker 数据目录迁移到受支持的本地文件系统。
五、检查残留挂载与目录状态
主机异常重启、Docker 进程被强制终止或存储设备短暂离线后，可能留下失效的 merged 挂载。可以使用 findmnt -t overlay 或 mount | grep overlay 检查当前挂载，再结合 docker inspect 容器名 判断对应容器是否仍被 Docker 管理。
若确认某个挂载已经脱离容器生命周期，应先停止 Docker，再谨慎卸载对应的 merged 路径。遇到 “device is busy” 时，可使用 lsof 或 fuser 查找仍在访问该目录的进程。⚠️ 不建议在 Docker 运行期间批量执行强制卸载，否则可能影响其他正常容器。
六、排查配置、权限与安全策略
检查 /etc/docker/daemon.json 是否为合法 JSON，并确认没有同时通过启动参数和配置文件设置冲突的 storage-driver 或 data-root。配置修改后，可先通过日志确认解析结果，再重启服务。
还应检查 Docker 数据目录的属主、权限和挂载选项。不要为了快速恢复而对 /var/lib/docker 执行递归 chmod 777，这会引入安全风险并破坏原有权限。启用了 SELinux 或 AppArmor 的系统，还需查看审计日志，判断挂载是否被安全策略拦截，而不是直接永久关闭安全机制。
七、针对单个容器或镜像进行恢复
如果只有一个容器失败，而其他容器正常，应优先怀疑该容器可写层或关联镜像层异常。先通过 inspect 保存容器配置、端口、环境变量和卷映射，再确认持久化数据是否位于独立 volume 中。数据安全后，可尝试删除并重新创建容器。
如果重新创建容器仍然失败，可重新拉取对应镜像。对于本地构建且无法重新获取的镜像，应先尝试导出或从构建源重建。不要手工删除某个看似无用的 overlay2 层目录，因为层 ID 与镜像元数据存在关联，误删可能导致更多镜像同时失效。
八、需要迁移或重建时的安全步骤
- 停止业务写入并备份数据库、volume 和关键配置。
- 记录 docker info、容器清单、镜像清单及 Docker 日志。
- 停止 Docker 服务，确认相关进程已退出。
- 使用保留属性的方式备份整个 Docker 数据目录。
- 修复或更换底层文件系统，并验证挂载参数。
- 重新启动 Docker，先测试非关键容器，再恢复生产业务。
切换存储驱动后，原驱动保存的本地镜像和容器通常不能直接被新驱动访问，因此必须先做好导出与备份。存储驱动的选择原则可参阅 Docker 存储驱动说明。
总结
✅ overlay2 挂载失败的正确排查顺序是：先收集日志并确认影响范围，再检查容量和 inode，随后核对内核、底层文件系统、残留挂载、目录权限及安全策略，最后才考虑重建容器、迁移数据目录或更换存储方案。处理过程中应坚持“先备份、后变更，先定位、后清理”，避免直接删除 /var/lib/docker/overlay2。对于数据库和其他关键数据，应使用独立 volume 并建立可验证的备份机制，从根本上降低存储层异常带来的恢复成本。
