Bottom Line: The NVMe Was Healthy, but It Was Not Mounted Into ZimaOS
The disk was never actually gone. PCI detection worked, lsblk showed /dev/nvme0n1, the partition existed, and later checks confirmed a valid GPT plus a readable vfat filesystem. The successful fix was to create the mount point under /DATA and mount the existing partition there. Once mounted, the files appeared in the ZimaOS Files app.
Verify the Disk Before You Format Anything
Start with evidence:
lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINTS
sudo blkid /dev/nvme0n1p1
sudo fdisk -l /dev/nvme0n1If the device, partition size and filesystem all look sane, do not wipe the disk just because the web UI does not list it. The Linux lsblk manual explains the block-device view, while blkid is the right tool for filesystem signatures.
Why /mnt Failed but /DATA Worked
ZimaOS uses a read-only squashfs root. Creating /mnt/nvme-test therefore failed with “Read-only file system” even though the NVMe itself was fine. Use the writable data area instead:
sudo mkdir -p /DATA/nvme-test
sudo mount /dev/nvme0n1p1 /DATA/nvme-test
ls /DATA/nvme-test
The current ZimaOS storage setup guide is the reference for storage managed through the UI. A manually mounted pre-existing disk is a different path, so verify the files first before deciding whether to migrate or reinitialize it.
What This Case Teaches
“Not in the storage UI” is not the same as “not detected.” Separate the layers: controller → block device → partition → filesystem → mount point → UI. That sequence prevents destructive guesses.
For storage-heavy builds, the ZimaCube 2 storage platform shows the current integrated NAS direction, while the NAS file-sharing guide covers the next step after a disk is available to the system.
