Been running ZimaOS for about a month now and my “boot” drive has filled up. Doing some digging I have found my .swap file to be 3.8GB! Restarting did not clear this out. However that’s only a small part of the lost space. Currently I am 46 GB Used of 48.3 GB but I am unable to see where the other 43GB has gone. In the UI is just says Data which is helpful!
What you’re seeing is actually quite common and usually not a fault.
The swap file growing to around 3 to 4 GB is normal behaviour. Linux does not automatically shrink swap after a reboot, so the space stays reserved on disk even if it’s no longer actively used. That said, swap alone isn’t what’s filling your boot drive.
The missing space is almost always Docker related. On ZimaOS, the boot disk stores Docker images, container layers, logs, and temporary overlay data. In the UI all of this is grouped under “Data”, which unfortunately doesn’t give much detail.
So in practice, that ~43 GB is likely coming from:
Docker images pulled when apps were installed
Container logs that have grown over time
Temporary overlay data created while containers are running
Because ZimaOS protects the OS filesystem, this space isn’t easily visible through the UI or Files app.
I believe and I suggest keeping the boot disk as light as possible, mapping all app data and media to /DATA, and avoiding installing too many apps before a large data disk is attached. A 48 GB boot disk works, but it doesn’t leave much headroom.
If the free space keeps dropping even when nothing is actively running, it’s usually log growth from a container rather than swap itself.
Thanks for the response! Just had a look again this morning and found I have magically gained 20GB! So something did a clean up overnight it seems. I have everything mapped to /DATA so in theory if I am understanding you correctly it shouldn’t have stored anything from the docker images in the boot SSD? What boot drive size would be recommended?
The recovered disk space is expected behaviour. ZimaOS and Docker perform periodic cleanups, such as pruning unused image layers, releasing temporary overlay data, and rotating logs. Gaining space back indicates the system is operating normally.
Even when all application data is mapped to /DATA, the boot drive will still be used for Docker engine files, image layers, runtime overlays, logs, and temporary cache data. Mapping /DATA prevents uncontrolled growth but does not eliminate boot disk usage entirely.
I believe and I suggest a boot disk size of:
- 64 GB minimum for light usage
- 128 GB recommended for most users
- 256 GB for heavier workloads or frequent app changes
A 48 GB boot disk can work, but it leaves limited headroom.
As a rule of thumb, if free space periodically recovers, the system is healthy. Continuous, unrecovered growth usually points to container logs or a misbehaving app.