結論：NVMeは正常でしたが、ZimaOSにマウントされていませんでした
ディスクが実際に消えていたわけではありません。PCI検出は正常に機能し、lsblkには/dev/nvme0n1が表示され、パーティションも存在していました。その後の確認で、有効なGPTと読み取り可能なvfatファイルシステムも確認できました。解決策は、/DATA配下にマウントポイントを作成し、既存のパーティションをそこへマウントすることでした。マウント後、ファイルはZimaOSのFilesアプリに表示されました。
フォーマットする前にディスクを確認する
まずは証拠を確認します。
lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINTS
sudo blkid /dev/nvme0n1p1
sudo fdisk -l /dev/nvme0n1デバイス、パーティションサイズ、ファイルシステムがすべて正常に見えるなら、Web 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ファイル共有ガイドでは、ディスクがシステムで利用可能になった後の次の手順を解説しています。
