結論：この ZimaOS+ のケースでは、「ストレージ容量の上限を超えました」は物理ディスクが満杯という意味ではなかった
ユーザーはすでに ZimaOS+ を利用していましたが、RAID と単一ディスクの構成を変更した後も、このエラーが発生しました。その後に行われた読み取り専用の確認では、実際のローカル RAID と 22 TB のボリュームは正常にマウントされていた一方、Files のストレージレイヤーには多数の古いエントリと、数多くのネットワークマウントが表示されていました。これらの状況から、原因はファイルシステムの容量不足ではなく、ストレージの容量計算または古いメタデータにあると考えられます。
まず、どのストレージが実在するのかを確認する
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS
df -h
findmnt /media
mount | grep /media実際のローカルディスクは、ブロックデバイスとして表示され、マウントされているはずです。UI にのみ表示される古いフォルダーは、別の問題です。lsblk のマニュアルとfindmnt のマニュアルは、安全に参照できる読み取り専用の資料です。
アクティブなマウントかどうかを確認するまで、/media のフォルダーを削除しない
このスレッドでは「ゴースト」ディレクトリが疑われていましたが、他の NAS デバイスからの正規の CIFS/SMB マウントも多数確認されました。古いものに見えるという理由だけでパスを削除すると、稼働中のマウントやアプリケーションのパスが壊れる可能性があります。まず一覧を確認し、その後は IceWhale が具体的なクリーンアップ手順を提供している場合を除き、サポートされているストレージ／共有 UI からのみ削除してください。
現在の ZimaOS ストレージガイドと、ZimaOS データ移行ガイドが、現行の参考資料です。
ストレージメタデータの初期対応として、工場出荷時リセットは負担が大きすぎる
リセットダイアログ自体から、アカウント、インストール済みアプリ、システム設定が影響を受けることが分かります。これは診断の近道ではなく、最後の手段です。まず、マウントの一覧と現在の ZimaOS バージョンを記録してください。
この 1.6.1 のケースを、現在も共通する普遍的なバグと呼ぶべきではない理由
ZimaOS のストレージ処理は、1.6.2 および 1.7 系列を通じて変更され続けました。現在のドキュメントでは、ローカルストレージ領域、ネットワークマウントされたストレージ、移行がより明確に分けられています。現在も同じエラーが発生する場合は、2026 年 5 月時点のバックエンドの状態がそのまま当てはまると決めつけず、現行リリースで再現し、正確なストレージ一覧を収集してください。
複数のドライブを使用する複雑なシステムについては、ZimaCube 2 マルチドライブストレージページで、現在のストレージアーキテクチャの背景を確認できます。
