ZimaOSで/root/.cacheが読み取り専用になる理由
mkdir /root/.cache: read-only file systemというエラーは、ZimaOSがホストシステムのファイルシステムの大部分をアプライアンス管理下の読み取り専用として扱っていることと一致します。元のスレッドでは、rootでログインしている場合でも、安全上の理由からシステムフォルダの大部分は読み取り専用のままであると、公式回答で明確に説明されています。
この設計は、現在のZimaOSパッケージマネージャーガイドや、関連するZimaOS Immich外部ライブラリガイドにも反映されています。
/rootへの書き込みを強制して回避しない
コンテナ化されたアプリケーションでは、通常、書き込み可能なキャッシュや設定データを永続的なアプリデータディレクトリに置き、それをコンテナ内にマッピングするのが適切です。immich-goのようなスタンドアロンツールでは、不変のホストレイアウトを変更するのではなく、キャッシュまたはホームのパスを、書き込み可能な場所に設定してください。
コンテナのパスを意図的に使用する
Dockerのバインドマウントは、書き込み可能なホストパスを、アプリケーションが想定するコンテナ内のパスにマッピングします。Docker公式のストレージドキュメントでは、Dockerバインドマウントのドキュメントで、バインドマウントとそのセキュリティ上の影響について説明しています。
Immichでは、変更ではなくインデックス作成が目的であれば、既存の写真フォルダを読み取り専用でマッピングできます。最新のImmich外部ライブラリのドキュメントが、上流プロジェクトによる正式な情報源です。
immich-goのより安全なパターン
- 保護されたシステムパスの外部にある、書き込み可能なユーザー／アプリデータディレクトリを作成または選択します。
- 対応している場合は、ツールのキャッシュ／設定用環境変数またはコマンドオプションで、その場所を指定します。
- コンテナ内で実行する場合は、その書き込み可能なパスを、想定されるキャッシュディレクトリにマウントします。
- ワークフロー上、元の写真を変更する必要がない限り、写真ライブラリのソースは読み取り専用でマウントします。
- ライブラリ全体を処理する前に、少量の写真でテストします。
rootアクセスがあってもすべてのパスに書き込めるわけではない理由
アプライアンスOSでは、root権限とファイルシステムの書き込み可否は別々に制御されます。rootシェルであっても、読み取り専用でマウントされたファイルシステムに遭遇することがあります。Linux環境によっては、システムパーティションを読み書き可能として再マウントできる場合もありますが、そうすると更新の前提や復旧動作が損なわれる可能性があるため、ここでの標準的な解決策にすべきではありません。
よくある質問
このエラーはディスクの故障を意味しますか？
必ずしもそうではありません。このコミュニティのケースでは、ストレージデバイスの故障を示すものではなく、意図的に読み取り専用にされたシステムパスが原因でした。
アプリケーションデータに/mediaを使用できますか？
ZimaOSが管理対象ディスク向けに公開しているストレージパスを使用し、それらを意図的にコンテナへマッピングしてください。アプリケーションの状態を移動する前に、所有者と権限を確認してください。
rootファイルシステムを読み書き可能として再マウントすべきですか？
通常の回避策としては推奨しません。更新後も維持でき、ZimaOSのストレージモデルに適合する、書き込み可能なアプリデータまたはユーザーデータのパスを優先してください。
