ZimaOS RAID5 Expansion Stuck at 0%: Check mdadm and Filesystem

Bottom Line: Verify Array Size and Filesystem Size Separately Before Rebuilding RAID 5

The old 1.4.1 UI showed a confusing state: the expansion reached 100%, Storage displayed the larger 36 TB total, Files still showed roughly the old usable capacity, and the expansion control remained stuck. That can mean the md array grew while the filesystem/UI did not complete its own resize or refresh. Do not infer success from one capacity card or failure from another.

ZimaOS RAID5 settings showing four 12 TB disks with expansion stuck at zero percent after previously reaching 100 percent — After the expansion reached 100%, the UI returned to an Expanding RAID state at 0% even though Storage displayed the larger raw capacity.

ZimaOS Files showing the RAID5 main storage still reporting the older usable capacity after expansion — The Files view still showed the pre-expansion usable space, which created uncertainty about whether only the array had grown or the filesystem had also expanded.

ZimaOS Storage overview showing RAID5 expansion status and larger 36 TB total capacity — Storage displayed a larger 36 TB total while still showing an expansion state, demonstrating why UI capacity alone was not enough to verify the operation.

Close-up of ZimaOS storage capacity showing 36 TB total after RAID5 expansion — The close-up highlights the new total capacity reported by the Storage interface after the fourth 12 TB disk was added.

Step 1: Check the RAID Member Count and Array State

cat /proc/mdstat
sudo mdadm --detail /dev/mdX

Confirm the new disk is an active member, the array state is clean, and no reshape/recovery is still running. The mdadm array status is the underlying Linux RAID reference.

Step 2: Check the Block Device and Filesystem Sizes

lsblk -f
df -h

If the md device is larger but the mounted filesystem still reports the old size, the RAID layer expanded but the filesystem did not. That is a different problem from a failed disk reshape.

Do Not Run Filesystem Growth Commands Blindly

EXT4, BTRFS and other filesystems use different expansion tools. Identify FSTYPE first. For EXT4, resize2fs is the relevant tool; for BTRFS, filesystem resize semantics differ. The EXT4 filesystem resize explains the EXT path.

Current ZimaOS Documents RAID 5 as Growable

Current RAID material explicitly says RAID 5 can grow by adding drives over time. That makes the old 1.4.1 behavior a historical expansion/UI problem rather than evidence that RAID 5 expansion is unsupported. The ZimaOS RAID5 expansion is the modern baseline.

Stop Heavy Apps Before a Multi-Day Reshape

The source user later rebuilt and successfully expanded twice after stopping containers and avoiding Files/Storage interactions during the operation. That is useful operational caution, but it does not prove that leaving Files open caused the original failure. The safer lesson is to reduce writes and UI interference during a long reshape, not to declare one browser tab the root cause.

Do Not Reboot Mid-Reshape Unless Recovery Requires It

RAID reshape is storage surgery. If /proc/mdstat shows active progress, let it finish unless the system is genuinely failing. Sudden power loss adds risk. Use a UPS for long expansions when possible.

Back Up Before Adding Another Drive

RAID 5 tolerates one member failure, but reshape increases activity across all disks and does not replace backup. The ZimaOS backup should be completed before a multi-day operation.

If the UI Still Says Expanding at 0%

After the array and filesystem are proven healthy and the filesystem sees the new size, a stale UI/service state becomes more plausible. Reboot only after storage activity has ended, then recheck. Do not break/recreate the array merely to clear a progress badge.

Rebuild Only as the Last Recovery Path

The original user ultimately backed up, broke the RAID and rebuilt it. That worked but is destructive. Today, use CLI state, current docs and backups to identify whether the array, filesystem or UI is actually wrong before choosing rebuild. The RAID recovery covers the recovery boundary.

FAQ

Why does Storage show more capacity than Files?

The RAID block device may have grown while the filesystem or Files UI still reflects the old size.

Can RAID 5 expand by adding drives in ZimaOS?

Current ZimaOS documentation says RAID 5 can grow by adding drives over time.

Should I close Files during expansion?

Reducing active writes is sensible, but the old thread does not prove an open Files tab caused the failure.

When should I run resize2fs?

Only after confirming the filesystem is EXT and the underlying block device is already larger.

Should I rebuild the array if the UI is stuck?

Not until mdadm and filesystem checks show an actual storage problem. A stale progress indicator alone is not enough.