关键是要定位空间耗尽位置、快速清理并预防复发：先用 docker system df、df -h 和 df -i 定位问题，再按日志、悬空镜像、卷等分类清理；挂载前确保宿主机空间充足，配置日志限制、tmpfs 和容量监控。
直接解决 Docker 容器在存储挂载期间因磁盘空间满导致的异常，关键不是“重启”或“重拉镜像”，而是定位空间耗尽的具体位置、快速释放可用空间，并防止再次发生。核心思路是：先止血（应急清理），再治本（配置优化）。
快速定位空间占用源头
挂载期间报错“no space left on device”，不代表整个系统磁盘满了，很可能是 Docker 数据目录（如 /var/lib/docker 或挂载目标路径）所在分区已满，或该路径下 inode 耗尽：
- 运行 docker system df 查看镜像、容器、卷、构建缓存各自占用量和可回收空间
- 用 df -h /path/to/your/mount 检查你挂载的目标路径（比如
/storage）是否真的满了 - 执行 df -i /path/to/your/mount 确认是不是 inode 用尽（IUse% ≥95% 就危险）
- 若挂载的是主机目录，进到该目录用 sudo du -sh * | sort -h 找出最大子目录
针对性应急清理操作
根据上一步发现的问题类型，选择对应清理方式，避免误删重要数据：
-
日志文件过大：常见于
/var/lib/docker/containers/**/logs/或挂载目录下的*.log文件。用sudo find /path -name "*.log" -size +100M -exec ls -lh {} \;找出大日志，再用sudo truncate -s 0 文件名清空（不删文件，避免服务报错） -
悬空镜像与构建缓存堆积：执行
docker system prune -f（清停用容器、悬空镜像、未用网络、构建缓存）；加-a可额外清理所有未被引用的镜像（谨慎使用） -
未使用的卷占空间：确认无业务依赖后，运行
docker volume prune；若需保留部分卷，先docker volume ls列出，再逐个docker volume rm 卷名 -
Windows 容器专用场景（如 dockurr/windows）：错误提示明确说
/storage需要至少 15GB，但只有 13GB——说明挂载目录空间不足。此时应检查宿主机对应路径剩余空间，而非在容器内操作
挂载时规避空间风险的配置方法
挂载本身不会消耗空间，但容器运行过程会往挂载点写入数据。必须提前规划容量并限制写入行为：
-
绑定挂载（-v）前确保宿主机路径有足够空间：例如
-v /mnt/win11-data:/storage，需保证/mnt/win11-data所在分区预留 ≥30GB（Windows 11 容器建议值） -
使用 Docker 卷时指定底层存储大小（仅限 local driver 支持）：如
docker volume create --opt o=size=50G windows_vol，再挂载该卷 -
限制容器日志大小：修改
/etc/docker/daemon.json，加入：{"log-driver": "json-file", "log-opts": {"max-size": "100m", "max-file": "3"}}，然后sudo systemctl restart docker -
对 Windows 容器等大体积应用，禁用默认 overlay2 缓存写入挂载点：通过启动参数
--tmpfs /tmp:size=2g或在 Dockerfile 中指定临时目录，避免中间解压文件挤占/storage
长期稳定运行的预防措施
光靠手动清理不可持续，需建立自动监控和容量兜底机制：
- 为挂载路径设置定时检查脚本，当可用空间 df /path | awk 'NR==2 {print $5}' | sed 's/%//' 提取百分比）
- 在 CI/CD 流水线中加入
docker system prune -f步骤，避免构建缓存持续累积 - Windows 容器项目建议直接使用外部 SSD 或独立挂载分区，避免与系统盘共用空间
- 生产环境禁用
--rm启动方式，改用命名容器 + 明确生命周期管理，便于跟踪数据归属
