ストレージパスの変更後にImmichで古いデータが表示される

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Immich Shows Stale Data After a Storage Path Change - Zima Store Online

ストレージパスの変更後にImmichのデータが古いままになる原因は、混同してはならない3つに分かれます。管理対象メディアのルート移動、外部ライブラリのインポートパス変更、またはクライアントがキャッシュ済みの状態を表示しているケースです。最新のImmichでは、設定済みのメディア保存場所とボリュームマウントが一貫していれば、移動した管理対象メディアの場所を調整できます。一方、外部ライブラリの移動は、新しいアセットの識別情報として扱われる場合があります。

再スキャンする前に、旧パスとデータベースを保持してください。まず、実行中のコンテナから見えるパスを確認し、次にImmichのサーバー側の記録が誤っているのか、それとも1つのクライアントだけが古い状態なのかを特定します。この違いによって、マウントを修復するのか、コンテナから見える安定したパスを復元するのか、テスト用の一部だけを再スキャンするのか、またはクライアントのキャッシュだけを削除するのかが決まります。

管理対象メディアのルート移動と外部ライブラリの移動を区別する

Immichが管理するアップロードのホスト上の保存場所を変更した場合は、実際に適用されているメディア保存場所の設定と、ホストからコンテナへのマウントが同時に変更されていることを確認してください。最新の管理対象メディアの移動は、外部ライブラリのインポートパスの名前変更と同じ方法で診断すべきではありません。

ZimaSpaceのImmich永続状態マップが役立ちます。データベースとファイルシステムのパスは、1つの復旧境界を形成するためです。ホスト上のファイルが正しくても、コンテナが別の場所にマウントされていれば不十分です。

管理対象メディアのルートが一致していない場合は、ライブラリジョブを実行する前に環境設定とボリュームマッピングを修正し、サービスを再起動してください。変更されたパスが外部ライブラリに属する場合は、データベースを保持し、その分岐を別途テストしてください。

可能な限り外部ライブラリのコンテナパスを固定する

外部ライブラリでは、コンテナから見えるインポートパスを変更せずにホスト側の保存場所を移動できる方法が最も安全です。Immichに提示されるパスが変わる場合は、スキャン前に少数のアセットID、アルバム、人物、旧パスを記録して、既存のアセットが再リンクされたのか、再作成されたのかを確認できるようにしてください。

Immichの外部ライブラリのパス変更に関する報告では、移動したファイルが新しいアセットとして扱われ、再処理とImmich内だけに存在する関連付けの消失が発生したと説明されています。これは特定バージョンに関する事例ですが、変更された外部ライブラリのパスが自動的に透過的な名前変更として扱われるとは限らない、という慎重な判断を裏付けています。

テスト対象の一部が新しいアセットとして表示され、古いレコードが見つからない状態またはゴミ箱に移動した状態になった場合は、全体の再スキャンを中止してください。可能であれば以前のコンテナから見えるパスを復元するか、使用中のバージョンに適した移行方法を利用してください。テスト済みのバックアップなしに、本番データベースのパスを手動で書き換えないでください。

この分岐を、Immichが管理するファイル向けのストレージテンプレート移行と混同しないでください。タイムライン上の症状は似て見えるかもしれませんが、ファイルの所有者とサポートされる移行方法は異なります。

保存されたサーバーパスとクライアントキャッシュを分けて確認する

同じ既知のアセットをWebクライアントと別の認証済みクライアントで確認し、サーバーログまたはサーバーから見えるパスと比較してください。サーバー側のジョブが依然として旧パスを示している場合、ブラウザーのキャッシュを削除しても根本的な記録は修復できません。

その後のImmichの旧パスのメタデータに関する問題では、名前変更後も処理が以前の外部ライブラリのパスを参照し続けていました。これは、モバイルやWebのUIを疑う前に、ジョブ側のパスを確認すべき強い根拠です。

サーバーのパスが正しいにもかかわらず、1つのWeb表示だけが古い場合は、そのクライアントのキャッシュを更新または削除して、元のファイルを再テストしてください。キャッシュされたサムネイルや古いクライアント状態によって、修正済みのサーバーが壊れているように見えることがあります。一方、キャッシュされたプレビューによって、壊れたサーバーパスが正常に見える場合もあります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

最小限のパス境界を修正し、管理された再スキャンを検証する

可逆性のある修正を1つだけ行います。管理対象メディアの設定とマウントを同期する、以前の外部ライブラリのコンテナパスを復元する、インポートパスを修正する、または1つのクライアントキャッシュを削除する、といった対応です。大規模なライブラリが再検出される可能性のある操作の前に、データベースをバックアップしてください。

実行可能な最小範囲で再スキャンし、既存のレコードとの関連付けが維持されるか、旧パスのエラーが止まるか、古いアセットと新しいアセットの重複が発生しないかを確認します。その後、サンプルのオリジナルファイルを開き、アルバムと人物の関連付けを確認し、検索を実行して、スタックを再起動してください。

古いパスと新しいパスのレコードが同時に有効なまま残る場合、大規模な外部ライブラリが予期せず再処理される場合、またはオリジナルファイルが読み取れるのに関連付けが消える場合は、さらに調査してください。変更前後の正確なマウント構成、Immichのバージョン、影響を受けたアセットID、ファイルシステムの大文字・小文字の扱い、データベースのバックアップ日時を保存してください。