大容量のHDDを追加した後もImmichがZimaOSのシステムSSDの空き容量を報告し続ける場合、重要なのは、どのホストディレクトリが実際にImmichのアップロード／ストレージマウントにバインドされているかです。2026年4月のコミュニティスレッドでは、元のユーザーは250 GBのシステムSSD上でImmich 2.7.4を実行し、写真を1 TBのHDDに保存したいと考えていました。インストール後にパスを繰り返し変更した結果、コンテナが異常な状態になったり、起動に失敗したりしました。
元のスレッドでは、いくつか異なる結果が報告されました。あるユーザーは、クリーン再インストールとカスタムYAMLの組み合わせで成功しました。原作者は最終的に、Immichをインストールする前にHDDのストレージパスを選択した場合にのみ成功したと報告しています。その後の返信では、一部の起動失敗がImmichのストレージ整合性チェックに関連している可能性が指摘されました。また、現在のImmich公式ドキュメントはバージョン2.7.4以降に変更されているため、この過去のZimaOSパッケージで使われていた正確なコンテナパスを、現在のすべてのImmichデプロイにそのまま適用すべきではありません。
原典のImmich 2.7.4セットアップで使用されていた構成
コミュニティの手順では、次の過去のマッピングが示されていました。
ホスト: /DATA/Gallery/immich
コンテナ: /usr/src/app/upload最初の推奨方法は、コンテナ側のパスを維持したまま、ホスト側だけを変更することでした。たとえば、セカンダリドライブをZimaOSのホストパス経由で公開し、Immichからは想定された内部アップロードディレクトリが見えるようにします。
ホストパスを単純に変更しても全員に効果がなかった理由
Immichの初期化が完了した後で、デフォルトのホストパスを置き換えようとしたユーザーも複数いました。コンテナが異常な状態になったユーザー、読み取り専用ファイルシステムのエラーが表示されたユーザー、アプリがシステムドライブを使っていると報告し続けたユーザーもいました。
つまり、このスレッドから「1つのボリュームを編集して再起動すれば必ず機能する」という普遍的な結論を導くことはできません。Immichはデータベースの状態とストレージ整合性マーカーを保持するため、初期化後にバインドマウントを変更すると、新しいディレクトリがImmichの想定する状態と一致しなくなる可能性があります。
原作者が確認した正常動作の方法
複数回の失敗を経て、Solidは4月19日に戻り、正常に動作した方法は、Immichのインストールが初期化される前にクリーンインストールを実行し、インストール先とストレージパスを1 TBのHDDに変更することだったと述べました。
2人目のユーザーがクリーンな再インストールとカスタムYAMLパスを確認
別の参加者であるscott492010は、失敗したインストールを削除し、既存の写真を保持したまま、古いImmichのAppDataとデータベースの状態を削除して再インストールし、その後スレッドで共有されたカスタムYAMLを使用しました。新しい設定が動作したことを明確に確認しています。
AppDataやImmichデータベースを安易に削除しないでください。このコミュニティ手順は、壊れたインストールまたはテスト用インストールで使用されたものです。ライブラリに重要なメタデータ、ユーザー、アルバム、アップロード済みアセットが含まれている場合は、再構築前にデータベースと写真ストレージの両方をバックアップしてください。
過去のZimaOSパス：/DATA/.media/...
スレッドでは、次のような外部ドライブのパスを試していました。
/DATA/.media/Elements/Photos
/DATA/.media/Elements/Photos/uploadこれらの例は、その説明で使用されたドライブとZimaOSのパスレイアウトに固有のものでした。名前をそのままコピーしないでください。 Elements または、すべてのドライブが同じホストパスに現れると決めつけないでください。現在のZimaOSのファイル設定またはアプリ設定に表示される実際のパスを使用してください。
現在のImmichでは異なるupstreamストレージレイアウトを使用
現在のupstream Immich Docker Composeドキュメントでは、次を使用します。 UPLOAD_LOCATION ホスト上で、そこをマウントして /data 現在のComposeテンプレート内。この設定は、過去のZimaOS Immich 2.7.4のマッピングとは異なり、 /usr/src/app/upload.
現在のImmich Docker Composeドキュメントを参照してください。
これは矛盾ではなく、バージョンの違いによるものです。ZimaOS App Storeパッケージを使用する場合は、現在のパッケージで定義されているコンテナ側の保存先を維持してください。upstreamのComposeを自分で管理する場合は、現在のupstreamテンプレートに従ってください。
カスタムファイル保存先に関する現在のImmichガイダンス
Immichには現在、専用のファイルのカスタム場所ガイドがあります。ホスト側の場所を意図的に変更し、Immichが既存のファイルを引き続き見つけられるよう、対応するファイルを移動することを推奨しています。
Immichは分割することも推奨していません。 upload/ および library/ 同じデバイス上の個別のバインドマウントに分割することです。新しい構成では、2026年のコミュニティYAMLを1行ずつ再現するのではなく、現在のストレージモデルに従ってください。
.immichファイルの欠落で起動が停止する理由
2026年7月のスレッドへの返信では、次のようなエラーが挙げられていました。
ENOENT: そのようなファイルまたはディレクトリはありません
.../encoded-video/.immich現在のImmichのシステム整合性ドキュメントでは、非表示の.immichファイルが、不正な権限やストレージマウントの欠落・置換を検出するために使用されるマウントマーカーであることが確認されています。
フォーラムの返信では、必要とされるフォルダーやマーカーファイルを手動で作成することが提案されていました。現在のアップストリームドキュメントでは、特定の復旧状況を除き、マーカーファイルを手動で作成または削除しないよう、より慎重な案内がされています。マウントが予期せず変更された場合は、まずマウントを修正してください。マーカーの欠落理由を確認できた場合にのみ、手動で再作成するのが適切です。
デフォルトの権限修正としてchmod 777を使用しない
最終的なコミュニティの返信でも、次のように述べられていました。
sudo chmod -R 777 /DATA/Main-Storage/immichこれにより、すべてのローカルユーザーとプロセスに広範な書き込みアクセス権が与えられます。アクセス権の障壁は取り除けるかもしれませんが、恒久的な権限モデルとして推奨される方法ではありません。代わりに、インストールされているImmichパッケージが想定するUID/GIDとストレージ権限を確認してください。
PostgreSQLデータベースを適切なファイルシステムに置く
写真アセットを大容量HDDに移動しても、Immichのすべてのコンポーネントをそこに置くべきとは限りません。現在のImmichの要件では、PostgreSQLデータベースはローカルSSDストレージに置くのが理想的であり、通常のUnixの所有権・アクセス権セマンティクスに対応したファイルシステムが必要です。データベースのデータディレクトリではNTFSとexFATはサポートされません。
Immichのインストール要件を参照してください。
つまり、信頼性の高いSSDストレージにImmichのデータベース／アプリ状態を保持しつつ、はるかに大容量の写真／動画のアップロード先を適切なセカンダリディスクに配置する構成は、合理的だと言えます。
既存のImmichデータを再構築または移動する前にバックアップ
現在のImmichドキュメントでは、データベースとファイルシステム上のアセットの両方を保護することを推奨しています。データベースのバックアップだけでは、元の写真や動画は含まれません。
より安全なトラブルシューティングの手順
- ZimaOSにインストールされているImmichパッケージ／バージョンを正確に特定してください。
- 現在のホストとコンテナ間のuploadマッピングを記録してください。
- 既存のImmichデータを変更する前に、重要な写真とImmichデータベースをバックアップしてください。
- 新規インストールでは、ZimaOSパッケージで指定できる場合、初回初期化の前に使用したい大容量ストレージのホストパスを選択してください。
- そのパッケージで定義されているコンテナ側のパスを維持してください。
- アプリが不健全な状態になった場合は、Immichのログを確認し、権限またはストレージ整合性に関するエラーを探してください。
- 新しいホストフォルダーがImmichコンテナのユーザーIDで書き込み可能であることを確認してください。
- 不足している
.immichマーカーを作成する前に、マウントとディレクトリ構造を確認してください。 - 避けてください
chmod 777恒久的な修正として。
Immichシステムストレージに関するFAQ
なぜImmichにはシステムSSDの容量が表示され続けるのですか？
アクティブなuploadのバインドマウントがシステムストレージを指したままか、変更したマウントが正常に初期化されなかった可能性があります。実行中のサーバーで使用されている、実際のホストとコンテナ間のマッピングを確認してください。
元の投稿者は解決できましたか？
はい。Solidの報告によると、インストール前にHDDのパスを選択したクリーンインストールは、インストール後の変更が失敗した場合でも正常に動作しました。
新しいImmichインストールに/usr/src/app/uploadをコピーすべきですか？
無条件にそうしないでください。これは過去のZimaOS Immich 2.7.4パッケージでのコンテナパスでした。現在の公式Immich Composeでは、 /data。実際に使用しているパッケージ／バージョンに従ってください。
.immichファイルを手動で作成すべきですか？
まず、なぜ不足しているのかを確認してから行ってください。現在のImmichドキュメントでは、特定の復旧ケースを除き、これらのマーカーを手動で作成または削除しないのが通常とされています。
データベースをexFATのUSBドライブに置けますか？
現在のImmichの要件では、PostgreSQLのデータディレクトリにexFAT／NTFSを使用できません。データベースは適切なローカルファイルシステム上に置き、必要に応じて写真アセットのみ別の場所へ移動してください。
