摘要：SSH 或控制台里出现 No space left on device 时，先用 df -h 和 df -i 分清是块空间满还是 inode 耗尽，再查日志轮转、journal、已删除未释放文件，以及容器/overlay 占用。依据阿里云、腾讯云与 systemd、Docker 官方文档；查询日期 2026-11-10。只放官网普通链接（affiliate_later）。

依据：阿里云《解决Linux实例磁盘空间满问题》、腾讯云《创建文件报错 no space left on device》、systemd journalctl 手册、Docker《Prune unused Docker objects》。查询日期：2026-11-10（北京时间）。只放官网普通链接（affiliate_later: 1）。命令与字段以你当前系统和官方当前页为准。不构成运维建议；文中命令、示例容量和百分比均来自上述页面，没在官方页写明的单价、阈值不另写。

SSH 登录后新建文件、写日志或跑应用，终端里突然出现 No space left on device，网站可能一起写不进去。先不要急着换系统盘或重装。宝塔里备份任务失败、日志切割把盘写满，见计划任务失败时的 cron 日志、权限与磁盘空间核对；MySQL 慢查询日志单独把盘占满，见慢查询日志怎么开、轮转与磁盘风险。本文只处理这条报错本身：先分清是块空间满还是 inode 耗尽，再核对日志、已删除未释放的文件，以及容器/overlay 占用。

阿里云这篇排障文在动手前写了一句重要提示：先手动创建单个快照备份数据，避免误删。腾讯云把原因分成三类：硬盘空间已满、文件系统 inode 满、df 与 du 结果对不上（常见是进程还握着已删除文件的句柄）。

1. 先跑 df -h 和 df -i，分清两种「满」

登录实例后，在同一台机器上把这两条都跑一遍：

sudo df -h
sudo df -i

阿里云的对照是：

你先看哪一列	怎样算满	常见含义
df -h 里的 Use%	某个挂载点到 100%	块空间耗尽，新数据写不进去
df -i 里的 IUse%	某个挂载点到 100%	inode 耗尽。每个文件占用一个 inode；磁盘上有大量小文件时，即使 df -h 还有剩余空间，也可能无法新建文件

腾讯云的处理顺序相同：先 df -h，再 df -i。看的时候对准你真正在写的那个挂载点，常见是根分区 /，也可能是单独挂载的 /var、/www 或数据盘。只看总容量、不看挂载点，容易把系统盘满和数据盘满搞混。

块空间这一侧，两家都是从根目录往下找大目录。阿里云写的是从 sudo du -sh /* 开始，定位到占用最大的目录后，再对该目录重复 sudo du -sh <目录名称>/*。腾讯云写的是进入对应挂载点后执行 du -x --max-depth=1 | sort -n（-x 不跨文件系统）。目录容量已经接近硬盘总空间，就继续往下钻，找到大文件后再按业务决定能不能删；目录容量远低于硬盘总空间，则转到「df 和 du 对不上」那一步。

inode 这一侧，阿里云建议用 sudo du -sh --inodes <目录名称>/* 查看指定目录下的文件和子目录占用了多少 inode，需要时再逐级往下看。腾讯云则给出一条按目录统计文件个数的 find 命令，并提醒这条命令比较耗时。小文件特别多的目录，常见是日志切割残留、缓存、或容器里堆出来的层文件。清掉无用文件后，若 inode 仍然不够，两家文档都指向扩容云盘。

2. 日志和 journal：先限制体积，别直接删正在写的文件

df -h 指向 /var 或 /var/log 时，先按阿里云给出的常见对象来核对，不要一上来 rm -rf：

类型	常见位置	文档里的处理口径
日志文件	/var/log	可清理归档的历史日志；systemd 日志建议使用 sudo journalctl --vacuum-size=200M 限制大小，不要直接使用 rm 删除正在写入的日志
临时文件	/tmp、/var/tmp	确认没有进程在用之后再清理
应用缓存 / 业务日志	业务自定义目录	清理前确认不是关键数据

systemd 官方手册把这组清理参数写得很清楚。你可以先看当前占用：

journalctl --disk-usage

手册写：--disk-usage 显示全部 journal 文件（含归档和仍在写入的活动文件）的磁盘占用总和。然后再按需要做真空清理：

sudo journalctl --vacuum-size=200M
sudo journalctl --vacuum-time=7d

这里的 200M 来自阿里云文档的示例；7d 是手册允许的时间单位示例（s / m / h / days / weeks / months / years）。--vacuum-size= 会删除最旧的已归档 journal，直到占用降到你指定的大小；--vacuum-time= 删除早于指定时间的已归档文件。手册还提醒：真空操作只处理已归档文件，不会删掉仍在写入的活动文件，所以跑完 --vacuum-size= 之后，--disk-usage 的数字不一定刚好等于你设的上限。三条参数可以合在一次命令里；也可以再带上 --rotate，先把当前活动文件归档，再执行真空，这样对「刚写进去的那一段」更有效。

网站日志、访问日志、应用自己的 info 日志，仍然按各软件的轮转配置处理。宝塔里如果是「计划任务」在切日志或备份时失败，回到前文的计划任务核对，不要和本次 df/inode 排查混成同一步。

3. df 已经很高，du 却加不起来：先查已删除未释放的文件

两家文档都写了这种情况：文件已经从目录里删掉，du 不再统计它，但还有进程握着文件句柄，空间就不会真正释放，df 仍然偏高。

阿里云的核对步骤是：先安装 lsof（Debian / Ubuntu 用 sudo apt install -y lsof），再执行：

sudo lsof | grep delete | sort -k7 -rn | more

输出第 7 列是文件大小（单位 Byte），可以累加估算还没释放的空间。记下 COMMAND 和 PID，用 sudo ps -ef | grep <PID> 确认这是哪个服务，评估影响后再重启或停止。文档强调：重启或停止服务可能影响业务，要选合适的时间。

腾讯云用 lsof | grep delete，再用 systemctl status <pid> 判断是不是 systemd 管理的服务：是服务就 systemctl restart 服务名；不是服务再按文档对对应进程做处理。进程很多时，文档提到可以重启服务器。无论哪一种，都先确认 PID 对应的是什么，再动手。

还有一类容易漏掉的「隐藏占用」：非空目录被另一块盘挂上去后，原目录里的数据会被挡住，已打开该目录的进程却还能继续往被覆盖的空间里写，df 看不到这一块。阿里云场景四的核对称是先 sudo lsblk 看有没有多个分区挂在同一 MOUNTPOINT，再评估后 umount 重复挂载、清理被挡住的那一侧。文档写明：不要把多个设备挂到同一目录。

4. 容器和 overlay：先看 docker system df，再按官方命令回收

df -h 里如果出现 Filesystem 为 overlay 且 Use% 到 100%，阿里云把它单独写成场景五：Docker 运行过程中会产生大量中间镜像、已停止容器和构建缓存，长期堆积会占盘。

下一步不是手动删 /var/lib/docker/overlay2 下面的目录，而是先看 Docker 自己的统计：

sudo docker system df

文档要你看 SIZE 和 RECLAIMABLE。它给的示例里，Images 占用 13.94GB，其中 10.66GB（76%）可回收，并建议优先清理无用镜像。对应的清理命令是：

• 清除所有已停止的容器：sudo docker container prune
• 清除所有 dangling 镜像（无 tag 的镜像）：sudo docker image prune
• 清除不再使用的构建缓存：sudo docker builder prune

Docker 官方《Prune unused Docker objects》写得更保守：这些对象默认不会自动删，除非你明确执行 prune，否则会继续占盘。docker system prune 可以一次清理多种未使用对象（含未使用的构建缓存）。默认的 docker image prune 只删除 dangling 镜像；要删除「当前没有被已有容器使用的全部镜像」，需要加 -a。官方命令在执行时会提示 WARNING! This will remove all dangling images. 并要求确认。数据卷默认不会被 docker system prune 清掉；只有在你明确加上卷相关参数、并确认那些卷不再被需要时才动。用 Docker 跑 WordPress 时，数据卷怎么备份、以及 down -v 可能误删，见用 Docker 部署 WordPress：compose、数据卷备份与升级。

如果这些命令回收不了，阿里云写：再回到场景一，按普通磁盘空间耗尽继续查大文件。不要把 overlay 目录当成普通文件夹手工删。

另外还有一种「看起来像空间不足、其实不是盘满」的情况。阿里云场景六写：执行类似 sudo tail -f 时出现 tail: cannot watch '...': No space left on device，可能是 inotify watches 到了上限，磁盘空间本身未必已经用完。核对入口是 sudo cat /proc/sys/fs/inotify/max_user_watches。文档提醒：调高上限会占用更多内存，修改前要评估；示例里一般不建议超过 524288。先确认 df -h / df -i 并没有 100%，再考虑这一条，避免把 inotify 上限误判成要扩容或重装。

5. 清完仍不够时，扩容优先于重装

阿里云和腾讯云在块空间、inode 清理之后，下一步都是扩容云盘。扩容涉及分区和文件系统伸展，步骤以云厂商当前文档为准；扩容前仍建议先做快照。系统已经无法启动、只能进救援或修复盘时，再按厂商的修复流程处理，这和「先重装碰运气」不是同一条路径。重装、数据盘是否保留、快照怎么回滚，仍然看换系统盘/重装系统：数据保留、快照回滚与排错顺序。

核对清单（可勾）

1. □ 操作前已经按阿里云提示创建了快照，或确认有可回滚的备份
2. □ 同时看过 sudo df -h 的 Use% 和 sudo df -i 的 IUse%，并对准实际写入的挂载点
3. □ 块空间满时，已用 du -sh /* 或 du -x --max-depth=1 下钻到具体目录
4. □ /var/log 和 journal 已按文档处理：可用 journalctl --disk-usage 和 --vacuum-size= / --vacuum-time=，没有直接 rm 正在写入的日志
5. □ df 明显高于 du 时，已用 lsof | grep delete 核对仍占着句柄的进程
6. □ 出现 overlay 且使用率到 100% 时，已先跑 docker system df，再按官方 prune 命令回收，没有手工删 overlay 目录
7. □ tail -f 报同样错误、但 df 并未 100% 时，已核对 inotify watches 是不是到了上限
8. □ 清理后空间仍不够，走的是扩容云盘；重装系统盘放到确认扩容和清理都不够之后，并按重装专文操作

相关阅读

• 云服务器换系统盘/重装系统：数据保留、快照回滚与排错顺序
• 宝塔计划任务失败：cron 日志、权限与磁盘空间核对
• 云服务器快照与自定义镜像：定时策略、保留份数与一键恢复演练
• MySQL慢查询日志怎么开：阈值、轮转与磁盘占满风险
• 用 Docker 部署 WordPress：compose 文件、数据卷备份与升级

官网入口（普通链接，无返利）：阿里云：解决 Linux 实例磁盘空间满问题、腾讯云：创建文件报错 no space left on device、systemd journalctl 手册、Docker：Prune unused Docker objects。