Immichのデータフォルダーで権限のずれを防ぐ方法

エヴァ・ウォン

IceWhale author

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

How to Prevent Permission Drift in Immich Data Folders - Zima Store Online

Immichで権限のずれを防ぐには、異なるコンテナ、NASプロトコル、アップデート、メンテナンスジョブによって異なる所有者情報のファイルが作成される前に、ファイルの所有権とアクセスルールを予測可能にしておく必要があります。

確実な解決策は、定期的に再帰的な権限リセットを行うことではありません。各ワークフローが実際に必要とする数値UID/GIDとアクセス権を記録し、マウントの所有権とACLの継承を意図的に設定し、読み取り専用パスと書き込み可能なパスを分離し、変更のたびに作成経路をテストします。明日作成される新しいファイルが緊急の`chown`なしで正しく作成されて初めて、権限のずれを防げたと言えます。今日のライブラリがたまたま読み取れるだけでは不十分です。

Immichの各パスを読み書きするIDを記録する

Immichにマウントされているホストパスを一覧化し、それぞれでどのプロセスがファイルの読み取り、作成、名前変更、削除を行う想定なのかを特定します。各書き込み元について、ホスト上とコンテナ内の数値UIDおよびGIDを記録します。ファイルの所有権は数値として保存されるため、ユーザー名を一致させることより数値IDの確認が重要です。

インベントリにはImmich以外の書き込み元も含めます。SMBアップロード、NFSクライアント、バックアップツール、インポートスクリプト、メディア管理コンテナ、管理者のシェルはいずれも同じツリー内にファイルを作成できます。これらが異なるIDで処理を行うと、ライブラリには、あるパスでは機能しても別のパスでは失敗する所有者やモードが徐々に蓄積します。

このIDの対応表はCompose設定と一緒に保管します。将来のイメージ更新、サーバー移行、NASアカウントの復元時に、既知の正常な基準と比較できるため、新しいアップロードが失敗してから不一致に気付く事態を防げます。

所有者、共有グループ、最小権限モデルを意図的に設定する

アプリケーションが管理するデータの所有者にするIDと、アクセスが必要な共有グループがあるかどうかを決めます。各ワークフローには、必要な読み取り権限または書き込み権限だけを付与します。1つのコンテナがサムネイルを作成できない、またはインポートしたファイルを移動できないという理由だけで、Immichツリー全体を誰でも書き込み可能にするのは避けてください。

UID/GIDの不一致と広すぎるモード設定は、共有ボリュームの障害を引き起こす一般的な原因です。より安全なのは、無制限のアクセスを許可するのではなく、コンテナとボリュームの権限を一致させるパターンです。複数のサービスが同じストレージプールに触れるホームサーバーでは、特に重要です。

複数のサービスに書き込みアクセスが必要な場合は、アプリケーション間で再帰的な所有権変更を繰り返すのではなく、共有グループと一貫したグループ権限、またはACLを使用します。まず代表的なディレクトリ1つで確認してください。写真ライブラリ全体に対する広範な再帰的変更は、最新のバックアップを用意したうえでの最終手段にすべきであり、通常のメンテナンスにしてはいけません。

新規ファイルの権限を予測可能にする

既存のファイルが完璧に見えても、作成ルールが誤っていれば新しいファイルはすぐに権限がずれます。そのパスに適用される親ディレクトリのACL、デフォルトACLエントリ、umask、サービスID、SMBまたはNFSの作成設定を確認します。防止すべき対象は後からの修正ではなく、継承の仕組みです。

モードを再帰的に変更する前に、ホスト上の数値所有権と、コンテナ内で実際に実行されているUID/GIDを比較します。このUID/GIDバインドマウント確認により、IDの不一致と本当に不足している権限をすばやく切り分けられます。寛容なモード設定で隠すのではなく、所有者とグループの関係を修正してください。

通常の書き込み経路ごとに小さなテストファイルを作成します。Immichのアップロード、インポートワークフロー、使用している場合はSMB/NFS転送、バックアップからの復元を対象にします。各テスト後に所有者、グループ、モード、ACLを確認します。2つの作成経路で互換性のない結果が出る場合は、さらにデータをインポートする前に、そのポリシーの衝突を解決してください。

-15% OFF

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

Single board computer zimaboard2

マウントや更新によって所有権が書き換えられないようにする

Composeの編集、イメージの更新、NASの再マウント、移行は、権限に影響する変更として扱います。適用前に、現在のマウント元とマウント先、パスが読み取り専用か読み書き可能か、実効コンテナユーザー、重要な各ディレクトリの数値所有権のサンプルを記録します。

転送やネットワークストレージでは、異なるSMB/NFS ID、数値ID、ACLの継承、umaskの動作が持ち込まれることがあります。Immichのデータをファイルシステム間またはアクセス方式間で移動する場合は、変更前のチェックリストとしてNASで権限が変わる際の障害ポイントを使用してください。

変更後は、一括ジョブを実行する前に同じサンプルを比較します。起動時に所有権が突然変わった場合は、スタックを停止し、どのエントリーポイント、メンテナンスタスク、またはIDの再マッピングが原因なのかを特定します。原因不明の再帰的な所有権書き換えを、大規模なライブラリ全体に適用し続けないでください。

小規模で再現可能なテストによってずれを監査する

スケジュールに従って、またはアップグレード後に、軽量な権限監査を実行します。変更されていないオリジナルを数件、最近のアップロード、新しく生成された派生ファイル、外部ライブラリのマウントを確認します。予期しない所有者、欠落したグループアクセス、書き込み可能に変わった読み取り専用マウント、期待どおりに継承されなくなったACLがないかを確認します。

続いて、エンドツーエンドの書き込みテストを行います。通常のクライアントから使い捨てのアセットをアップロードし、Immichに処理させ、開いてからアプリケーション経由で削除します。外部ライブラリやインポート経路を使用している場合は、それらの経路から代表的なファイルを1つ追加し、所有権を予期せず変更することなくImmichが読み取れることを確認します。

Immichの再起動後とホストの再起動後も、新しいファイルが意図したIDとアクセス権を受け取り続けて初めて、防止のループが完了します。どちらかのイベント後に手動修復が必要になるなら、システムはまだずれています。アクセス範囲を広げる前に、作成ルールまたはIDマッピングを修正してください。