ZimaOS Storage Limit Exceeded: Real Mounts vs Stale Entries

Bottom Line: In This ZimaOS+ Case, “Storage Limit Exceeded” Did Not Mean the Physical Disks Were Full

The user already had ZimaOS+ and still hit the error after rearranging RAID/single-disk layouts. Read-only checks later showed the real local RAID and 22 TB volume were mounted normally, while the Files/storage layer displayed many old entries and numerous network mounts. The evidence points to storage accounting or stale metadata—not a full filesystem.

ZimaOS dialog showing Storage limit exceeded while trying to create RAID0 — The error appeared while changing two 4 TB disks from single volumes into a new RAID0 storage space.

First Prove Which Storage Is Real

lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS
df -h
findmnt /media
mount | grep /media

A real local disk should appear as a block device and mount. A stale folder visible only in the UI is a different problem. The lsblk manual and findmnt manual are the safest read-only references.

ZimaOS Files storage view showing many stale numbered storage folders after previous RAID and mount changes — The Files view showed many old numbered storage entries that no longer corresponded to the user's current physical disks.

Do Not Delete /media Folders Until You Know Whether They Are Active Mounts

The thread suspected “ghost” directories, but it also showed many legitimate CIFS/SMB mounts from other NAS devices. Deleting a path because it looks stale can break a live mount or application path. Inventory first, then remove only through the supported storage/share UI unless IceWhale provides a specific cleanup procedure.

The current ZimaOS storage guide and ZimaOS data migration guide are the current references.

A Factory Reset Is Too Expensive as a First Storage-Metadata Fix

ZimaOS reset dialog showing accounts apps and settings removed while storage arrays and user files are retained — A factory reset was considered late in the thread, but the evidence still pointed toward storage-service metadata rather than disk corruption.

The reset dialog itself shows that accounts, installed apps and system settings are affected. It is an escalation step, not a diagnostic shortcut. Capture the mount inventory and current ZimaOS version first.

Why This 1.6.1 Case Should Not Be Called a Current Universal Bug

ZimaOS storage handling continued changing through 1.6.2 and the 1.7 series. Current docs separate local storage spaces, network-mounted storage and migration more clearly. If the same error appears now, reproduce it on the current release and collect the exact storage inventory rather than assuming the May 2026 backend state still applies.

For complex multi-drive systems, the ZimaCube 2 multi-drive storage page provides the current storage architecture context.