別の HDD または SSD にすでに写真があり、それらを Immich の通常のアップロードライブラリへ移動せずに ZimaOS 上の Immich でインデックス化したい場合は、External Library を使用してください。2024年10月のコミュニティスレッドでは、まず ZimaOS のホストフォルダーを immich-server コンテナに公開し、その後 Immich の管理画面で対応するコンテナ側のパスを追加する、このワークフローが確認されています。
これは、Immich のプライマリアップロードストレージを変更することとは異なります。同じスレッドの後の返信では、外部ディスクを今後のすべての Immich アップロードの唯一の保存場所にできるか尋ねていましたが、その質問は原典スレッドでは解決されませんでした。現在の Immich ドキュメントでは、既存ファイルには External Libraries を使用し、 UPLOAD_LOCATIONImmich が管理するアップロード用のカスタムストレージパス。
原典スレッドで実際に解決されたこと
原作者は、デフォルトの保存場所の外部にある写真を Immich に認識させようとしていました。その後、次の手順で成功したと報告しています。
- ZimaOS で Immich の設定を開きます。
- immich-server サービスを開きます。
- ZimaOS のホストフォルダーを Docker ボリュームとして追加します。
- 次のようなコンテナ側のパスを使用します。
/home/user/photos1. - Immich の管理画面を開きます。
- External Library を作成し、同じコンテナ側のパスを追加します。
後のユーザーが、この解決策が自分の環境で機能したことを明確に確認しています。
ホストパスと Immich パスは異なる
Docker のマッピング概念は次のとおりです。
ZimaOS ホストフォルダー → Immich コンテナフォルダー例：
/media/Photos:/home/user/photos1:roImmich は ZimaOS のホストパスを直接スキャンしません。スキャンできるのは、コンテナ内から見えるパスだけです。
/home/user/photos1既存の写真アーカイブには読み取り専用モードを使用する
元のコミュニティによる解決策では、次を使用していました。 :ro。Immich がファイルのインデックス作成だけを行う場合、現在の Immich ドキュメントでも読み取り専用マウントが推奨されています。
/media/Photos:/home/user/photos1:ro読み取り専用モードを使用すると、Immich がファイルを削除したり、ソースフォルダーにサイドカーメタデータを書き込んだりするのを防げます。
現在の Immich External Library ドキュメント
Immich で External Library を作成する
マウントが作成されたら、管理者アカウントで Immich を開き、External Libraries セクションに移動します。ライブラリを作成し、所有者を選択して、コンテナ内のパスを追加します。
/home/user/photos1続いてスキャンを実行します。Immich は写真のインデックス作成と、サムネイルおよびメタデータのジョブ作成を開始するはずです。
コンテナ内にパスが存在することを確認する
Immich がライブラリパスを拒否する場合は、マウントが次の場所から見えることを確認してください。 immich-server。原典スレッドの核心的な問題は、Immich の UI でフォルダーを選ぶことだけではありませんでした。Docker がまず、そのフォルダーをコンテナ内に公開する必要がありました。
現在の Immich ドキュメントでは、同じ要件が明記されています。マウントしたパスは、External Library として追加する前にコンテナ内に存在していなければなりません。
過去の Database タブの手順を盲目的にコピーしない
2024年の原典投稿では、Immich Database タブにも同じパスを追加するよう記載されていました。この手順は、現在では慎重に扱うべきです。
現在の上流版 Immich では、次のように分かれています。
- UPLOAD_LOCATION または外部ライブラリのバインドマウントを通じた写真／動画ストレージ
-
PostgreSQLデータベースストレージ（
DB_DATA_LOCATION）経由
データベースの場所は、フォトライブラリの場所と同じではありません。以前のZimaOSパッケージに「Database」サービスのタブがあったからといって、任意の写真フォルダーをPostgreSQLにマッピングしないでください。
外部ライブラリとImmichのプライマリストレージの違い
| 目的 | 次を使用します |
|---|---|
| 別の場所にすでに保存されている写真をインデックスする | 外部ライブラリ |
| 今後のImmichへのアップロードを別のドライブに保存する | Immichのアップロード／ストレージ場所を変更する |
元のスレッドで確認されたのは1つ目のケースであり、2つ目ではありません。
外部ドライブをImmichのメインストレージにしたい場合
現在のImmich Docker Composeでは、次を使用します。
UPLOAD_LOCATION=./libraryそして、そのホストパスを次にマウントします /data 内部 immich-server。現在のカスタムロケーションに関するドキュメントでは、想定されるコンテナパスを維持しながら、Immichが管理するデータを別のホストストレージ場所へ移動する方法を説明しています。
Immichに重要な写真がすでに存在する場合は、プライマリストレージの場所を変更する前に、データベースとファイルシステムの両方をバックアップしてください。
データベースの要件と写真ストレージを分けて考える
PostgreSQLデータベースには写真ファイルとは異なるストレージ要件があります。現在のImmichドキュメントでは、データベースパスでネットワーク共有はサポートされておらず、データベースには適切なローカルファイルシステムを使用する必要があると説明されています。
外部フォトライブラリを追加するだけの理由でPostgreSQLを移動しないでください。
外部ライブラリにも個別のバックアップが必要です
Immichは、外部ライブラリのアセットの元データを通常の管理対象ストレージにコピーしません。元データは外部ディスクに残ります。ディスク上のファイルが削除されると、再スキャン後にImmichがそれらを欠落としてマークしたり、アクティブなライブラリから削除したりする場合があります。
ソースドライブは個別にバックアップしてください。Immichのデータベースメタデータは、ファイルシステムのバックアップの代わりにはなりません。
ZimaOS上のImmich外部ライブラリチェックリスト
- 写真が入っている既存のZimaOSホストフォルダーを特定します。
- 現在のImmichアプリ／コンテナの設定を開きます。
- ホストフォルダーをマウントします
immich-server. - 次を推奨します
:roImmichが変更すべきでないアーカイブ用です。 - 次のような分かりやすいコンテナパスを使用します
/home/user/photos1または/mnt/media/photos. - Immichの管理画面 → 外部ライブラリを開きます。
- コンテナ側の正確なパスを追加してください。
- ライブラリスキャンを実行します。
- これをImmichのプライマリストレージの移動と混同しないでください
UPLOAD_LOCATION. - 外部ドライブは別途バックアップしてください。
Immich外部ストレージに関するよくある質問
元の解決策は機能しましたか？
はい。元の投稿者が成功したと報告しており、後日、別のユーザーも同じワークフローが自分の環境で機能したと確認しています。
外部ライブラリを使用すると、外部ドライブがImmichのメインアップロード先になりますか？
いいえ。外部ライブラリは、Immichの管理対象アップロードストレージの外部にすでに存在するファイルをインデックスします。
Immichにはどのパスを入力すればよいですか？
ZimaOSホストのパスではなく、Dockerのマウントで指定したコンテナ側のパスを使用してください。
:roを使用すべきですか？
はい。外部フォルダーがImmichによる読み取り専用のアーカイブである場合はそうしてください。Immichがそこにあるファイルを変更または削除する意図がある場合のみ、読み取り専用モードを解除してください。
