ZimaOSでは現在、従来のCasaOSスタイルのMergerFS「ストレージ統合」ワークフローはストレージUIに表示されず、フォーラムのスレッドでも復活するという公式な約束はありませんでした。ユーザーに表示された apt: command not found という結果も、ZimaOSが通常のDebianホストではなく、アプライアンス型のシステムであることと一致します。
重要な違いは、MergerFSがRAIDではなく、ファイルレベルのプーリングである点です。複数の独立したファイルシステムを1つのディレクトリとして表示できますが、パリティ、冗長性、スナップショット、RAIDのような再構築機能は追加されません。
ZimaOSでaptが使えない理由
ZimaOSは高度な作業向けにSSHとウェブターミナルを提供していますが、だからといって、ルートOSが任意のパッケージインストールを想定して設計されているわけではありません。現在のZimaOS SSH設定ではターミナルアクセスについて説明されていますが、現在の開発者向けドキュメントでは、通常の動作時にルートファイルシステムが読み取り専用であることも説明されています。
つまり、apt install mergerfsを実行してZimaOSを変更可能なDebianサーバーにしようとするのは、誤った前提です。仮にパッケージを手動で導入できたとしても、将来のOSアップデートによって変更が上書きされたり、無効になったりする可能性があります。
MergerFSが実際に行うこと
上流のMergerFSドキュメントでは、複数のファイルシステムパスを1つの統合ディレクトリにまとめつつ、基盤となるファイルシステムには個別にアクセスできる仕組みが説明されています。また、RAIDのような冗長性とパリティは非対応機能として明示されています。
これは元の要望によく合っています。つまり、1台の物理ドライブを失っても、他のすべてのドライブが自動的に失われるわけではない大容量のメディア用名前空間を構築できます。ただし、プールされたビューを使用する場合でも、失いたくないファイルには別途バックアップ戦略が必要です。
Dockerによる回避策は実験的なものとして扱う
フォーラムの返信では、DockerでMergerFSを実行する方法が提案されていました。これはコミュニティによるアイデアであり、IceWhaleがサポートするストレージモードではありません。コンテナ内のFUSEファイルシステムでは、昇格された権限、デバイスへのアクセス、マウント伝播の設定が必要になる場合があり、ZimaOSのストレージ管理、SMB共有、アプリのパス選択とうまく統合できない可能性があります。
安定した本番環境用のプールが必要な場合は、まずサポート対象のRAIDまたはZFSレイアウトが適しているかを検討してください。ストレージプール計画ガイドでは、容量、パフォーマンス、障害ドメインを分けて検討する方法を説明しており、RAIDとSnapRAIDの選択肢では、保護モデルの異なる代替手段を取り上げています。
結論
2026年のフォーラムでの要望は妥当ですが、ZimaOSには現在もMergerFSをネイティブに有効化するボタンがあるとは文書化されていません。aptが利用できないことを、ターミナルの故障と解釈しないでください。また、特権付きのDocker MergerFSコンテナを、従来のCasaOSの統合機能に代わる公式な方法と見なしてはいけません。独立したディスクによるプーリングが必須なら、まず重要でないデータでテストし、別途バックアップを維持してください。
