결론: NVMe는 정상이었지만 ZimaOS에 마운트되지 않았습니다
디스크가 실제로 사라진 것은 아니었습니다. PCI 감지는 정상적으로 작동했고, lsblk에는 /dev/nvme0n1이 표시되었으며, 파티션도 존재했습니다. 이후 확인 결과 유효한 GPT와 읽을 수 있는 vfat 파일 시스템도 확인되었습니다. 문제를 해결한 방법은 /DATA 아래에 마운트 지점을 만들고 기존 파티션을 그곳에 마운트하는 것이었습니다. 마운트가 완료되자 ZimaOS 파일 앱에 파일이 표시되었습니다.

포맷하기 전에 디스크 확인하기
먼저 다음 명령으로 상태를 확인하세요.
lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINTS
sudo blkid /dev/nvme0n1p1
sudo fdisk -l /dev/nvme0n1
장치, 파티션 크기, 파일 시스템이 모두 정상으로 보인다면 웹 UI에 표시되지 않는다는 이유만으로 디스크를 지우지 마세요. Linux lsblk 매뉴얼에서는 블록 장치 정보를 확인하는 방법을 설명하며, blkid는 파일 시스템 시그니처를 확인하는 데 적합한 도구입니다.


/mnt에서는 실패했지만 /DATA에서는 작동한 이유
ZimaOS는 읽기 전용 squashfs 루트를 사용합니다. 따라서 NVMe 자체에는 문제가 없었지만 /mnt/nvme-test를 만들려고 하면 “Read-only file system” 오류가 발생합니다. 대신 쓰기 가능한 데이터 영역을 사용하세요.
sudo mkdir -p /DATA/nvme-test
sudo mount /dev/nvme0n1p1 /DATA/nvme-test
ls /DATA/nvme-test

현재 제공되는 ZimaOS 스토리지 설정 가이드는 UI를 통해 관리되는 스토리지에 대한 참고 자료입니다. 기존 디스크를 수동으로 마운트하는 방식은 별도의 경로이므로, 마이그레이션하거나 다시 초기화하기 전에 먼저 파일을 확인하세요.
이 사례에서 배울 점
“스토리지 UI에 표시되지 않음”은 “감지되지 않음”과 같은 뜻이 아닙니다. 컨트롤러 → 블록 장치 → 파티션 → 파일 시스템 → 마운트 지점 → UI의 각 계층을 구분하세요. 이러한 순서를 따르면 파괴적인 추측을 피할 수 있습니다.
스토리지를 많이 사용하는 구성에서는 ZimaCube 2 스토리지 플랫폼에서 현재 통합 NAS의 방향을 확인할 수 있으며, NAS 파일 공유 가이드에서는 디스크를 시스템에서 사용할 수 있게 된 다음 단계에 대해 설명합니다.
