Immichはなぜ所有者が間違った状態で欠落ファイルを再作成するのですか？

エヴァ・ウォン

IceWhale author

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

Why Does Immich Recreate Missing Files With the Wrong Owner? - Zima Store Online

Immichは、失われた元ファイルを汎用的な復旧機能として、密かに再作成すべきではありません。削除したオブジェクトが再び現れた場合は、まずそれが生成されたサムネイル、エンコード済み動画、プロフィール用アーティファクト、XMPサイドカー、または別の書き込み可能なファイルなのかを確認してください。これらは異なるプロセスによって再作成または書き換えられる可能性があり、別の所有者を引き継ぐことがあります。

再生成された使い捨てオブジェクトを1つと、その親ディレクトリを使用します。ホスト上の数値UID/GIDとACLを、コンテナ内で実際に書き込みを行うプロセスの実効UID/GIDおよびグループと比較し、実際にそれを作成したのがImmich、サイドカー書き込み機能、NASプロトコル、その他のホストプロセスのどれなのかを特定してください。書き込み元が判明するまでは、再帰的なchownやchmod 777は避けてください。

再作成されたファイルを親ディレクトリおよび正常な既存ファイルと比較する

再作成されたファイル、その親ディレクトリ、そして正常に動作する古いファイルについて、所有者、グループ、モード、ACL、必要に応じて拡張属性、数値UID/GIDを記録します。NASとコンテナ間では名前が誤解を招くことがあります。数値IDを使えば、あるシステムの「immich」が別のシステムでも同じIDに対応しているかを確認できます。

NASに移動したファイルに関するZimaSpaceの権限ワークフローがそのまま当てはまります。新しいオブジェクトは、移行先のACL、コンテナのID、プロトコルのマッピング、作成ルールによって管理されます。そのため、置き換えられたファイルは読み取り可能であっても、別のツールのワークフローを壊す所有者になることがあります。再作成されたファイルが親ディレクトリの継承設定と一致し、表示名だけが見慣れない場合は、何かを変更する前に数値IDを対応付けてください。親ディレクトリとも正常な既存ファイルとも異なる場合は、書き込み元のIDを確認してください。問題はファイルシステムのACLではなく、コンテナ設定の内部にある可能性があります。

置き換えファイルを書き込むプロセスと実効UID/GIDを特定する

関連するログとファイルシステムを監視しながら、安全な再生成を1回実行します。書き込みを行うコンテナ内で、実効ユーザーとグループを確認してください。代わりにサイドカー、メタデータツール、バックアッププロセス、またはホストスクリプトがファイルを作成している場合は、Immichの実行IDを変更するのではなく、そのサービスを調べてください。

コンテナの所有権は名前ではなく数値で管理されます。Dockerにおけるファイル所有権の解説では、UID/GIDのマッピングが一致しない場合、同じバインドマウントされたファイルでもホストとコンテナで異なるユーザー名が表示される理由が説明されています。共通の基準として数値IDを使用してください。

Immichの外部ライブラリの所有権に関する議論では、ある環境でXMPサイドカーがrootとして書き込まれていました。これは、実効的な書き込み元とサポートされている実行IDを確認するための事例であり、現在のすべてのImmich環境が再生成されたすべてのファイルをrootとして書き込むという主張ではありません。

コンテナを意図的に非rootユーザーとして実行している場合は、そのUID/GIDがホストまたはNAS上に実際に存在し、マウントされたパスへの必要なアクセス権を持っていることを確認してください。コンテナ内の記号的なユーザー名は、同じ名前を持つホストアカウントと自動的に一致するわけではありません。

既存ファイルを繰り返し修正するのではなく、作成ルールを修正する

確認できた最小限の境界を修正します。サポートされている場合はサービスのUID/GIDを揃え、親ディレクトリのグループまたはACL継承を修復し、適切なumaskを設定するか、誤ったIDを提供しているNAS共有のマッピングを変更してください。Immichと、正当な他の読み取り元が元ファイルおよび生成ファイルにアクセスできる状態を維持します。

デフォルトの修復方法として、全ユーザーに書き込み可能な権限を設定しないでください。これではIDの不一致が隠れ、不要な書き込みアクセスが広がります。同様に、PostgreSQL、モデルキャッシュ、アップロード、外部ライブラリを1つのコマンドで再帰的に変更しないでください。これらのパスでは、意図的に異なるサービスIDが使われている場合があります。

外部ライブラリを変更不可にする場合は、使用する機能がその場所へのサイドカー書き込みを必要としないことを確認したうえで、マウントを読み取り専用にし、アプリが所有する書き込み可能な状態を別の場所に保持することを検討してください。重要なのは写真アーカイブ内のすべてのファイルを1つのアカウントに統一することではなく、望ましい所有権と書き込み動作を決めることです。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

もう一度ファイルを1つ再作成し、再起動後に検証する

安全に再作成できる生成オブジェクトまたはテスト用サイドカーだけを削除し、同じImmich操作をもう一度実行します。新しい所有者、グループ、ACLを確認し、Immichと、以前に失敗した別のプログラムの両方から読み取れることを検証してください。このテスト中は元のメディアに触れないでください。

コンテナを再起動し、その後ホストも一度再起動して、修正したIDとマウントがライフサイクルの変更後も維持されることを確認します。修復が成功していれば、次に作成されるテストファイルは期待どおりの所有権で自動的に作成されます。Immichの書き込みと競合する、起動後に実行するchownスクリプトに依存することはありません。

所有権の変更がデータベースや元ファイルに予期せず広がった場合、または再起動後にサービスが読み書きできなくなった場合は、停止して保存しておいた設定から復元してください。数値ID、ACLの出力、マウントオプション、実効コンテナユーザー、Composeの該当部分、そしてImmichが再作成した正確なファイル種別を添えて、サポートにエスカレーションしてください。