Plexのデータフォルダーで権限のずれを防ぐ方法
Plexの権限ドリフトを防ぐには、数値による実行時IDを一定に保ち、復元時の所有権を維持し、appdataとメディアへのアクセスを個別にテストします。
イメージの更新、ホストの移行、スタックの再作成、バックアップの復元後に権限エラーが発生することがあります。これはファイル自体は残っていても、数値による所有者、グループ、ACL、または想定される実行時ユーザーが変わるためです。最も安全な予防策は、`/config`とメディアに関する正常な基準状態を把握し、変更のたびに簡単な確認を1回行うことです。基準状態からツリー全体に同じ所有権が本当に必要だと確認できない限り、広範囲に及ぶ再帰的な権限修正は避けてください。
権限を変更する前に数値による所有権を記録する
使用している数値UIDとGIDを把握し、appdataとメディアのパスに保存されている数値上の所有者を確認しておくと、権限ドリフトを最も簡単に防げます。ホストとコンテナでユーザー名が異なっていても、ファイルシステムは数値を基準に適用します。
数値UIDとGIDのマッピングにより、コンテナのプロセスをホストの所有権に合わせられます。ユーザー名や記憶に頼らず、スタック設定にこれらの値を記録してください。
システムが正常な状態で、appdataディレクトリ、データベースファイル、メディアディレクトリをそれぞれ1つずつ選び、`stat`の出力または同等の情報を取得します。これらを、イメージ更新、ホスト移行、復元、ストレージ移動後に比較する基準にします。
コンテナ更新後も実行時IDを一定に保つ
イメージの更新によって、デフォルト値、エントリポイントの動作、環境変数の解釈方法が変わることがあります。実際に実行されるPlexプロセスが別のIDで起動すると、新しく作成されるファイルの所有者が変わり、後の再起動時に古い状態へアクセスできなくなる可能性があります。
プラットフォームやイメージの変更後に、appdataへの書き込みアクセスの喪失が発生した場合、実際の実行時IDが、更新対象のファイルと一致しなくなった可能性があります。
イメージまたはホストをアップグレードするたびに、実行中のコンテナ内でプロセスのUID/GIDを確認し、適切であれば、書き込み可能な使い捨てパスにテストファイルを1つ作成します。数値が予期せず変わっていた場合は、新しい所有権が広がる前に実行時設定を修正してください。
appdataへの書き込みアクセスとメディアへのアクセスを分ける
Plexのアプリケーション状態には通常、読み取りと書き込みの両方が必要です。一方、メディアライブラリは、他のツールによるファイル管理を意図的に許可するワークフローでない限り、読み取りのみで十分な場合があります。両方のパスに同じ広範な権限セットを付与すると、実際に必要な役割が分かりにくくなり、ミスの影響範囲も広がります。
安定したコンテナアクセスは、制限のないモードビットではなく、PUIDとPGIDの整合に依存します。恒久的な対策として全ユーザーに書き込み権限を与えるのではなく、サービスの役割に合わせてアクセスを設定してください。
`/config`、メディア、トランスコード用の一時領域について、必要なアクセスを個別に定義します。変更後は、それぞれのパスに対してPlexプロセスでテストを行ってください。読み取り専用のメディアパスでファイルを削除できないのは意図した動作かもしれませんが、appdataパスでデータベースのジャーナルを作成できないのは問題です。
復元時に所有権とACLを維持する
バックアップにPlexのファイルがすべて含まれていても、復元ツールが管理者アカウントでファイルを書き込んだり、ACLを削除したり、グループ所有権を変更したりすると、権限ドリフトが発生することがあります。その場合、次に起動するコンテナからはデータが完全にそろっているように見えても、一貫して更新できません。
起動前に、復元された所有権を実行時IDと比較する必要があります。これにより、完全なバックアップを復元しても、読み取れないappdataツリーになる事態を防げます。
復元テストでは、チェックサムやファイル数だけでなく、所有者、グループ、モード、ACLの扱いも確認してください。少量のサンプルを別の場所に復元し、メタデータを比較します。ツールが権限を維持できない場合は、復元後に所有権を設定する手順を運用手順書に明記してください。
サンプルの復元に成功したら、実際の復旧で使用するものと同じツールおよびオプションで確認を繰り返します。別の手動コピー方法に依存した権限維持テストでは、本番のバックアップワークフローが安全だとは証明できません。
再帰的な修正ではなく、小さなテストでドリフトを監査する
再帰的な`chmod`や`chown`コマンドを使うと、Plexを再び起動できるようになる一方で、メディア、バックアップ、共有アプリケーションデータ間で意図的に異なっていた権限まで書き換えてしまう可能性があります。より安全な保守方法は、ドリフトが発生した正確なパスを特定し、必要な所有権またはアクセスだけを修正することです。
appdataの権限チェックに失敗した場合は、マウント、所有者、ACL、ユーザーを変更する前に、Plexの実行時IDで対象パスをテストしてください。
コンテナの置き換えと同時に権限が変わる場合、コンテナの永続化ワークフローで、実行時IDとデータの保存場所を連動して管理する必要があります。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
