Docker挂载失败报“no space left on device”时，根本原因在于宿主机挂载点或Docker根目录（如/var/lib/docker）空间或inode耗尽，需用df -h和df -i精准定位，再针对性清理日志、执行docker system prune或迁移data-root路径。
遇到 Docker 容器在挂载存储时因磁盘空间不足报错（如 No space left on device 或 failed to mount volume），问题通常不在容器内部，而是宿主机的存储路径或 Docker 自身数据目录已满。关键要分清“挂载点空间”和“Docker 根目录空间”两层，再针对性清理或迁移。
确认到底是哪块空间满了
挂载失败不等于系统盘满，需快速定位瓶颈：
- 运行
df -h查看所有挂载点，重点关注容器 volume 所映射的宿主机路径（比如/data、/mnt/vol1）是否已 ≥90% - 同时检查
docker info | grep "Docker Root Dir"对应路径（通常是/var/lib/docker）是否也快满——它影响镜像拉取、容器启动、卷元数据写入等底层操作 - 若挂载的是
emptyDir或未指定 hostPath 的临时卷，实际占用的是 Docker overlay2 可写层，此时要查du -sh /var/lib/docker/overlay2/* | sort -hr | head -5
快速释放挂载点或 Docker 根目录空间
先让挂载流程恢复，再深入清理：
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
- 对挂载目标目录（如
/data）：用find /data -type f -name "*.log" -size +50M -exec truncate -s 0 {} \;清空大日志，避免删除导致应用丢失句柄 - 对
/var/lib/docker：执行docker system prune -af（慎用--volumes，除非确认无业务数据卷）；再配合journalctl --vacuum-size=100M压缩系统日志 - 若发现某容器日志异常膨胀，用
docker inspect <container> | jq '.HostConfig.LogConfig'查日志配置，并手动清空其LogPath文件（truncate -s 0 /var/lib/docker/containers/xxx/xxx-json.log）
从配置上堵住源头
单次清理治标，固定策略才能防复发：
- 为所有新容器强制限制日志大小：在
/etc/docker/daemon.json中添加{"log-driver":"json-file","log-opts":{"max-size":"50m","max-file":"3"}}，然后systemctl reload docker - 挂载 volume 时显式指定宿主机路径，并确保该路径所在分区有足够余量（建议预留 ≥20%）；避免直接挂载根分区或
/var下子目录 - 对长期运行服务，改用
hostPath挂载到独立大分区（如/mnt/data），并在 Pod 中通过resources.ephemeral-storage声明临时存储需求，让 K8s 调度器提前规避空间紧张节点
必要时迁移 Docker 数据目录
如果 /var/lib/docker 所在分区持续告急，且无法扩容，就迁移到大磁盘：
- 停掉 Docker：
systemctl stop docker - 用
rsync -avz /var/lib/docker/ /mnt/bigdisk/docker/同步（保留权限和硬链接） - 修改
/etc/docker/daemon.json，加入"data-root": "/mnt/bigdisk/docker" - 重启 Docker：
systemctl daemon-reload && systemctl start docker，再用docker info确认路径已生效
