Bottom Line: If the RAID Works but ZimaOS Says the NVMe Disks Are Missing, Suspect Slot Mapping Before Disk Failure
On several Beelink ME Mini installations, RAID 0/5 storage remained readable and writable over SMB while the dashboard showed missing NVMe disks or wrong free-space information. That pattern means Linux and the RAID layer can already see the devices. The broken layer is the ZimaOS physical-slot mapping/UI.


First Prove the NVMe and RAID Are Healthy Underneath the UI
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS
lspci | grep -i "Non-Volatile"
cat /proc/mdstat
df -h
If the RAID is mounted, SMB works and the expected NVMe devices appear in lspci/lsblk, do not rebuild the array just to fix the dashboard. Current ZimaOS storage screens are intended to show disk health, capacity and read/write information once the mapping is correct.
The ZimaOS storage status provides the expected end state.
NVMe Mapping Uses PCI Addresses, Not lsblk HCTL

The old non-Zima hardware fix used lspci for NVMe. lsblk -o hctl is the SATA/SCSI branch and can return nothing useful for NVMe. This distinction resolved confusion in the thread.
The Historical local-storage.conf Fix
IceWhale's non-Zima hardware workaround used /etc/casaos/local-storage.conf and updated the NVME mapping to match the PCI addresses exposed by lspci, followed by:
systemctl restart zimaos-local-storage
Later users found the actual parser behavior in their builds required space-separated addresses rather than the comma-separated example originally published. Because this is an old low-level workaround, back up the config and prefer current ZimaOS behavior first before editing it manually.
The non-Zima disk mapping preserves the historical procedure.
What a Corrected NVMe View Looks Like





Once mapping is correct, the dashboard can show each SSD model, size, temperature and usage instead of placeholder missing-disk cards. The fix changes how ZimaOS associates physical PCI devices with visual slots; it does not repair filesystem data.
How to Check NVMe Health Independently of the UI
nvme list
nvme smart-log /dev/nvme0
smartctl -a /dev/nvme0
The nvme-cli health checks provides the standard Linux NVMe tooling. Use it when the dashboard is questionable but you still need drive-health evidence.
When You Should Not Edit Slot Mapping
If the NVMe device is absent from lspci and lsblk, you do not have a UI-only problem. Check BIOS, drive seating, slot protocol, power and hardware compatibility first. A slot-map edit cannot make a physically undetected drive appear.
The ZimaCube 2 storage and RAID recovery provide safer reference architectures.
FAQ
Why does my Beelink RAID work when ZimaOS shows missing disks?
Linux can assemble and mount the RAID even if the ZimaOS visual slot map does not match the Beelink's PCI topology.
Should I recreate the RAID to fix missing NVMe cards?
No. If the data is readable and the array is healthy, fix or report the UI mapping instead of destroying a working array.
Why does lsblk -o hctl show nothing?
NVMe devices are PCIe devices and the old workaround used lspci addresses. HCTL is more relevant to SCSI/SATA-style device mapping.
Can I still use nvme-cli if ZimaOS UI is wrong?
Yes, if the device is visible to Linux. nvme smart-log can provide health, temperature and error counters independently of the dashboard.
Is local-storage.conf editing still the recommended first step?
No. It is a historical workaround for non-Zima hardware. Test the current release first and preserve a config backup before manual edits.
