解决docker overlay2挂载失败，核心是使宿主机内核模块、文件系统d_type支持、docker配置三者对齐：需安装对应kernel-modules-extra包、验证xfs的ftype=1或ext4的fsck修复、显式配置daemon.json为overlay2、排除selinux/secure boot拦截。
volume本身不直接挂载overlay2，报错实际来自docker使用overlay2作为存储驱动时，宿主机内核与底层支撑能力不匹配。核心是让宿主机内核模块、文件系统特性、docker配置三者对齐，而非调整volume。
确认overlay内核模块是否就绪
内核升级后常见问题：模块未随新内核安装，导致Docker初始化overlay2失败。
- 运行 uname -r 查当前内核版本，再执行 ls /lib/modules/$(uname -r)/kernel/fs/overlayfs/overlay.ko —— 若提示“no such file”，说明模块缺失
- RHEL/CentOS系：执行 yum install kernel-modules-extra-$(uname -r)
- Ubuntu/Debian系：执行 apt install linux-modules-extra-$(uname -r)
- 加载测试：sudo modprobe overlay && lsmod | grep overlay；失败时用 dmesg | tail -20 查具体原因（如 signature required 或 Invalid module format）
验证/var/lib/docker所在分区是否支持d_type
overlay2强制要求该路径所在文件系统启用d_type，否则容器启动时报 missing d_type support。
- 若为XFS：运行 xfs_info /var/lib/docker | grep ftype，输出必须是 ftype=1；若为0，需备份数据后重新格式化：mkfs.xfs -n ftype=1 /dev/xxx
- 若为ext4：默认支持d_type，但仍建议执行 sudo fsck.ext4 -f /dev/sdXY 排除元数据损坏
- 注意：不要用已弃用的 overlay（非overlay2）驱动临时绕过，它会掩盖d_type缺失问题
正确配置Docker存储驱动并排除干扰
Docker不会自动降级或适配，必须显式指定且确保能完成初始化。
- 编辑 /etc/docker/daemon.json，写入：
{"storage-driver": "overlay2"}
不要长期启用overlay2.override_kernel_check=true - 内核低于 3.10.0-514（如CentOS 7.2及更早）时，overlay2不可用，应升级内核；若无法升级，可改用 fuse-overlayfs（需额外安装并配置）
- 重启服务：sudo systemctl restart docker，再运行 docker info | grep "Storage Driver"，确认输出为 overlay2 且无warning
检查SELinux与Secure Boot是否拦截
内核升级后，SELinux策略或Secure Boot可能阻止模块加载或挂载操作，表现为“挂载失败”实为权限拦截。
- 临时测试：sudo setenforce 0 关闭SELinux，再运行 docker run hello-world；若成功，说明需更新策略而非修改Docker配置
- 生产环境持久修复示例：
semanage fcontext -a -t container_file_t "/var/lib/docker(/.*)?"
restorecon -Rv /var/lib/docker - Secure Boot启用时，未签名模块会被拒绝加载；可临时禁用定位问题，但不应长期关闭
