Community Solution

Beelink ME Mini NVMe Missing in ZimaOS UI: Diagnose It

Beelink ME Mini users could read and write NVMe RAID pools while the ZimaOS dashboard misidentified drives or reported incorrect pool usage.

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.

ZimaOS Storage showing a RAID5 pool with NVMe disks reported as missing on a Beelink ME Mini
The pool remained accessible, but ZimaOS rendered four NVMe slots as missing even though the underlying RAID was working.
ZimaOS Storage showing a RAID0 pool with NVMe members missing from the visual slot map
A second pool showed the same mismatch: usable RAID storage underneath, incorrect physical-disk presentation in the dashboard.

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

ZimaOS terminal where lsblk -o hctl returns only the HCTL header for NVMe devices
This failed diagnostic illustrates a common mistake: HCTL is useful for SCSI/SATA-style devices, while NVMe mapping needs PCI addresses instead.

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

ZimaOS RAID5 pool displaying three TEAMGROUP NVMe SSDs with health temperatures and zero percent used
A later Beelink setup showed the intended result: individual NVMe models, capacity and temperatures visible in the Storage interface.
ZimaOS RAID5 pool showing three Crucial 2 TB NVMe SSDs with health and temperature information
Another corrected configuration exposed NVMe model names, usage and temperatures rather than placeholder missing-disk cards.
ZimaOS RAID5 storage screen showing three Crucial 4 TB NVMe SSDs detected correctly
A working slot map with three 4 TB NVMe drives showed that the issue was UI mapping rather than RAID functionality.
ZimaOS Storage showing six NVMe disks missing in the dashboard before correcting the NVMe PCI mapping
All six NVMe positions appeared missing even though the pool existed, reinforcing that the visual slot configuration was wrong.
ZimaOS RAID5 pool showing six Crucial NVMe SSDs correctly after the PCI address mapping was updated
After correcting the NVMe PCI address mapping, all six SSDs appeared with model, capacity and temperature data.

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.