外观
系统盘满了
适用范围
系统盘指 OMV 所在的根文件系统 /。它写满之后，常见的表现有：
- 密码正确却登录失败（官方排障页给出的经验），或者界面报 502、
Failed to connect to socket。 - 保存设置、安装更新失败，
apt报No space left on device。 - 容器起不来，或者应用写不进日志。
- 收到 monit 的邮件，提示根文件系统（
rootfs）使用率过高。
不适用：数据盘写满了，那是清理数据或扩容的问题，和系统盘无关。
开始排查前
清理就是删除，先分清哪些能删、哪些不能删
影响范围：本页的清理步骤会删除日志、缓存和镜像。系统盘上其他位置的文件，例如 Docker 卷、应用数据库、你自己放的文件，删了就无法恢复。
前置条件：每一步都先用只读命令确认占用者和内容，再动手。Docker 的 volumes 目录里往往是应用的真实数据，不要执行会清理卷的命令（docker volume prune、docker system prune --volumes），也不要手工 rm -rf /var/lib/docker。
回退办法：删掉的日志和缓存会重新生成；其他删除只能靠备份恢复，系统盘的备份方法见备份系统盘：backup 插件。
排查步骤
1. 确认是系统盘，看看有多满
sh
# 在 OMV 的 shell 里执行（只读）
df -h /
df -i /df -h / 看容量使用率。df -i / 看 inode，使用率 100% 而容量没满，说明小文件太多。
OMV 的 monit 在根文件系统使用率超过 85%（环境变量 OMV_MONIT_SERVICE_FILESYSTEM_ROOT_USAGEWARNTHRESHOLD）并持续一段时间后发出告警，前提是邮件通知可用，且「监测 - 文件系统」通知项开着。
2. 找出谁占了空间
sh
# 在 OMV 的 shell 里执行（只读）
du -xh --max-depth=1 / 2>/dev/null | sort -h | tail -n 12-x 表示不跨文件系统，挂载在 /srv 下的数据盘不会被算进来。顺着最大的目录一层层往下查，例如 du -xh --max-depth=1 /var | sort -h | tail -n 12。
官方排障页里把这条命令写成了 df -hx --max-depth=1 /，但 --max-depth 是 du 的选项，应当用上面的 du。
常见的大户：
| 位置 | 是什么 | 怎么处理 |
|---|---|---|
/var/lib/docker | Docker 的镜像、容器层和卷，Compose 插件默认把 Docker 存储放在这里 | 先用 docker system df 看明细；长期做法是把 Docker 存储迁到数据盘，见Compose 插件设置详解 |
/var/lib/containers | Podman 的存储 | 同上 |
/var/log、/var/log/journal | 日志。OMV 8.1.1 起把 journald 的上限设为 1 GiB（环境变量 OMV_SYSTEMD_JOURNALD_SYSTEMMAXUSE），约合三个月的日志 | journalctl --disk-usage；日志短时间暴涨，就去找刷屏的服务 |
/var/cache/apt、/var/lib/apt/lists | apt 的下载缓存和索引 | apt-get clean |
/srv/dev-disk-by-uuid-…，而数据盘当前并没有挂载 | 数据盘没挂上时，写进挂载点目录的数据其实落在系统盘上 | 见第 4 节 |
/root、/home、/tmp | 手工下载或复制的大文件 | 确认之后手工清理 |
| 备份类插件、Timeshift 等 | 备份目标误设在系统盘上 | 改到数据盘或外部盘 |
3. 清理最安全的部分
- apt 缓存，随时可以重新下载：
sh
# 在 OMV 的 shell 里执行
apt-get clean- 旧日志，保留最近 200 MiB：
sh
# 在 OMV 的 shell 里执行；删除的是已归档的旧日志，不影响当前日志
journalctl --vacuum-size=200M- Docker：先只读地看明细。
sh
# 在 OMV 的 shell 里执行（只读）
docker system df回收空间的做法是：在 服务 → Compose → 镜像（Services → Compose → Images）里删除没有被任何容器使用的镜像，具体按钮以你界面上的显示为准。卷不要动。
- 你自己放在
/root、/tmp等位置的大文件，确认不需要之后删除。
4. df 与 du 对不上
df 说满了，du 加起来却小得多，常见两种原因：
- 已删除但仍被进程占用的文件，例如某个服务的日志被删了，进程还开着它。
sh
# 在 OMV 的 shell 里执行（只读）
lsof +L1找到占用的进程之后，重启那个服务或容器，空间才会释放。
- 数据盘没挂载时，数据被写进了挂载点目录，后来盘挂上，这些数据被「盖住」了，
du看不到，df却一直在计数。先确认现在是否已挂载，再用绑定挂载看看被盖住的内容：
sh
# 在 OMV 的 shell 里执行
findmnt /srv/dev-disk-by-uuid-<UUID>
mkdir -p /mnt/rootview
mount --bind / /mnt/rootview
du -xh --max-depth=2 /mnt/rootview/srv 2>/dev/null | sort -h | tail
umount /mnt/rootview看到被盖住的数据之后，不要直接删：先弄清是容器还是备份任务在盘没挂上的时候写进去的，把需要的数据移到真正的数据盘，再清理。盘为什么没挂上，见磁盘或文件系统不见了。
5. 空间释放之后
- 检查有没有失败的服务：
systemctl --failed。 - 界面仍然报错，按502 Bad Gateway 与 Failed to connect to socket检查三个后台组件。
- 容器没有自动起来，见重启后容器没起来。
6. 防止再次写满
- 数据和容器数据放数据盘。 在 Compose 设置里指定放在数据盘上的共享文件夹，并规划好 Docker 存储的位置。
- 监控根文件系统。 在
系统 → 通知 → 事件（System → Notification → Events）里确认「监测 - 文件系统」是开着的，并配置好邮件，见配置邮件通知。 - 系统盘要留够容量。 官方文档对在 Debian 上手动安装的建议是：根分区至少 4 GiB，最佳 120 GiB。
- 谨慎使用 sharerootfs 插件。 它允许把共享文件夹建在系统盘上，容易把系统盘写满，见在系统盘上建共享文件夹：sharerootfs。
- 系统盘是 U 盘或 SD 卡的，再装上 writecache，见减少系统盘写入：writecache 插件。
确认恢复
df -h /显示使用率回到官方告警线（85%）之下，并留有余量。- 重新登录 Web 界面，保存一个设置，确认能成功写入。
systemctl --failed没有失败的单元，容器都起来了。- 重启一次，几天后再用
du复查，确认没有重新增长。
仍未解决
附上：df -h、df -i 的输出，du -xh --max-depth=1 / 的前 12 行，docker system df 和 journalctl --disk-usage 的输出。读如何有效求助。
参考资料
- OMV 官方文档：Troubleshooting（系统盘满导致登录被拒）、系统要求
- OMV 8 更新记录：8.1.1 加入 journald 上限环境变量，见OMV 8.1–8.5 更新要点
- 本站：仪表盘、系统信息与性能统计、系统盘怎么选：SSD、U 盘与 SD 卡