This source ultimately produced a confirmed IceWhale root cause. After upgrading to ZimaOS 1.5.3, the NVMe RAID array itself assembled and mounted, but zimaos-local-storage immediately unmounted it because the RAID database contained fs_type = 'BTRFS' in uppercase instead of the lowercase value expected by the storage manager.
Dina from IceWhale provided a targeted SQLite update. The original poster ran it and explicitly confirmed the RAID mounted normally afterward. ZimaOS 1.5.4 then listed the uppercase-BTRFS RAID auto-mount issue as an official fixed item. Current users should therefore treat the SQL as historical recovery guidance for that exact bug, not as a general RAID repair command.
The RAID Array Was Healthy Before the Storage Manager Unmounted It
The journal showed the kernel autodetecting RAID, systemd mounting /media/RAID-Storage-2, and then zimaos-local-storage force-unmounting it seconds later.
The source database record also showed the RAID as status ok. That made a failed member or destroyed Btrfs filesystem less likely.
Manual fstab Worked Only as a Temporary Workaround
The user manually mounted the RAID and added an /etc/fstab entry, but ZimaOS storage management did not treat that as the authoritative configuration. On reboot, the local-storage service still enforced its internal database/state.
This is why appliance-managed storage should normally be repaired through the ZimaOS storage layer instead of maintained as a parallel manual mount.
The Community Correctly Identified zimaos-local-storage as the Layer
Before IceWhale posted the root cause, gelbuilding noticed the key sequence: mount succeeds, then zimaos-local-storage unmounts it. He correctly advised sending logs to IceWhale rather than repeatedly modifying RAID metadata.
His speculation about stricter validation was not the final diagnosis; the later official diagnosis was much more specific.
IceWhale Found the fs_type Capitalization Error
Dina wrote that the database fs_type value was capitalized, causing the mount to fail. IceWhale provided:
sudo sqlite3 /var/lib/casaos/db/local-storage.db "UPDATE raids SET fs_type = 'btrfs' WHERE fs_type = 'BTRFS';"The user later replied: “This indeed fixed the issue.”
BTRFS to lowercase btrfs.ZimaOS 1.5.4 Officially Fixed the Same Auto-Mount Bug
The 1.5.4 release notes explicitly list a fix for automatic mount failure when RAID database records stored BTRFS in uppercase.
See the official ZimaOS 1.5.4 RAID mount fix.
A Later 1.5.4 User Still Reported RAID Not Mounted
Another participant said a mount problem still occurred on their 1.5.4 system. Dina asked for a fresh disk diagnostic and symptom description rather than assuming it was still the uppercase-fs_type bug.
That is the correct boundary: similar symptoms can have different causes.
Do Not Run the Old SQL on a Current RAID Without Matching Evidence
Current ZimaOS is 1.7.1. Before touching local-storage.db, verify that:
- the array actually assembles;
- the journal shows the local-storage service unmounting it;
- the database truly contains the historical uppercase value;
- you have a current backup and diagnostic report.
If those conditions do not match, editing the database can make a different storage problem harder to recover.
The Official Fix Was Found Because the User Supplied the Right Logs
IceWhale asked for /ZimaOS-HD/.log/casaos/local-storage.log after the community identified the storage-manager layer. That log let the team move from a broad theory to the exact capitalization bug.
For a current mount failure, preserve the same evidence pattern: RAID assembly status, journal lines, ZimaOS storage status, and local-storage diagnostics before modifying metadata.
Back Up Internal Metadata Before Any Manual Database Edit
The source SQL was an IceWhale-provided one-line correction for a known 1.5.3 defect. If a staff-guided database edit is ever required again, make a backup of the database/state first and apply only the exact condition being corrected.
Broad SQL updates against RAID records can disconnect the storage manager's view from the real array and turn a recoverable mount bug into a metadata-recovery problem.
A Reinstall Is Not the First Response to a Healthy-but-Unmounted RAID
Because the array itself assembled and the data was intact, reinstalling or recreating RAID would have been unnecessarily destructive. When a healthy array is being rejected by management metadata, repair the management layer or use vendor support before touching the array geometry.
RAID Mount FAQ
Was the RAID itself destroyed in the source?
No. The array assembled and mounted before ZimaOS storage management unmounted it.
What was the confirmed root cause?
The RAID database stored fs_type as uppercase BTRFS instead of lowercase btrfs.
Did IceWhale fix this in a release?
Yes. ZimaOS 1.5.4 explicitly lists the uppercase-BTRFS auto-mount bug as fixed.
