スタックを再作成すると、Plexが永続データにアクセスできなくなるのはなぜですか？
スタックを再作成した後に Plex が初期状態になった場合は、古い永続データが実際に失われたと確認できるまで、マウントまたは権限の問題として扱ってください。
Docker または Compose のスタックを再作成すると、コンテナが置き換えられるだけでなく、/config を支えるホストパス、名前付きボリューム、ユーザー ID、ストレージプールが変わることがあります。その結果、Plex は空のディレクトリや読み取り不能なディレクトリを開き、元のデータベースが残っているにもかかわらず、新規インストールのように見えます。新しいインスタンスを停止し、古い appdata の場所を探し、実際のマウントと数値所有者を比較してください。その状態が本当に失われている場合にのみ、バックアップから復元します。
Plex が新規サーバーのように見えたら停止する
スタック再作成後に初回セットアップウィザードが表示されても、それはライブラリを再構築する合図ではなく、永続化に関する警告です。Plex がさらに状態を書き込む前に、コンテナを停止してデータマッピングを確認してください。最もよくある問題は、新しいコンテナが以前のアプリケーションデータディレクトリではなく、空のホストパスを読み取っていることです。
再作成されたコンテナでは、想定していた永続的な設定マッピングが元の appdata を指さなくなると、初回セットアップが表示されることがあります。まず確認すべきなのは、古い状態がホスト上にまだ存在しているかどうかです。
以前の Plex データディレクトリを見つけ、変更日時、データベースファイル、メタデータフォルダーを確認してください。それらが存在する場合は、削除したり新しいサーバーを初期化したりしないでください。復旧の対象はメディアライブラリではなく、マウントパスと権限です。
古い /config マッピングと新しいマッピングを正確に比較する
スタックを再作成すると、コンテナ内で表示されるパスが変わらなくても、相対バインドマウント、名前付きボリューム、環境変数の置換、ストレージプール、Compose の作業ディレクトリが変わることがあります。Plex からは依然として /config に見えていても、そのパスが別のホスト上の場所を指している可能性があります。
Plex コンテナの構成では、設定データをコンテナの外部に置くのが最も安全です。見た目が似ている Compose ファイルを信用するのではなく、以前のデプロイ記録またはバックアップと、再作成したスタックの実際のマウントを比較してください。
既知の古い appdata を一時的な診断用コンテナに読み取り専用でマウントするか、ホスト上で直接確認してください。想定していたデータベースと設定が存在するなら、本番のマッピングを修正して Plex を一度だけ再起動します。ディレクトリ自体が本当に存在しない場合は、バックアップからの復旧に進んでください。
データベースを疑う前に所有権を確認する
ホストパスが正しくても、再作成されたコンテナが別の UID、GID、ユーザーネームスペース、またはセキュリティコンテキストで実行されていると使用できない場合があります。その場合、データが正しい場所にマウントされていても、Plex は設定を保存できず、データベースファイルを開けず、ディレクトリも作成できないように見えます。
Plex が appdata を作成または更新できない場合は、再帰的な 777 を盲目的に適用して「修正」するのではなく、設定ディレクトリの権限を数値で確認してください。
コンテナ内で ID を確認し、ホスト上の数値所有者およびモードと比較してください。意図したサービスアカウントにアクセス権を与えるために、必要最小限の所有権または ACL の修正を行います。その後 Plex を起動し、新しいセットアップではなく既存のサーバーを開くことを確認してください。
数値上の所有権が一致しているのにアクセスできない場合は、データベースを変更する前に ACL、コンテナのセキュリティラベル、ユーザーネームスペースの動作を確認してください。UID/GID が正しくても、別のアクセス制御レイヤーがあればアクセスできないことがあります。
アプリケーションの状態が戻ってからメディアマウントを確認する
古いサーバー ID とライブラリが再び表示された後も、/config とは別にメディアマウントが変更されていると、一部のライブラリが利用できないように見えることがあります。これは別の永続化の役割です。ライブラリを再作成したり、メディアをアプリケーションデータディレクトリにコピーしたりせず、メディアパスを修正してください。
アプリケーションの状態とメディアマウントは、別々の永続化の役割として維持してください。これにより、まず Plex の ID を復元し、元のライブラリが再表示された後で、見つからないメディアパスを調査できます。
Plex コンテナ内から、既知のメディアパスをいくつか開いてください。古いデータベースが /media/movies を参照しているのに、再作成されたスタックが /movies を公開している場合は、想定されるコンテナ内パスを復元するか、管理されたライブラリパスの移行を計画してください。マウントが安定するまで再スキャンしないでください。
元の状態が本当に失われた場合にのみバックアップから復元する
古いホストディレクトリが空、削除済み、または使用できないほど破損している場合は、最新の正常な Plex appdata のバックアップを、正しくマッピングしたクリーンなパスに復元してください。何が起きたのかを引き続き調査できるよう、失敗した状態は別に保存し、唯一の証拠を上書きしないでください。
信頼できるコンテナ復旧ワークフローでは、永続的な /config を保護し、使い捨てのアプリケーション層だけを置き換え、Plex が再び書き込めるようにする前にマウントを検証します。
復元後は、サーバー ID、ライブラリ数、視聴状態、ローカル再生、使用している場合はトランスコード、そして再起動を一度確認してください。その後、実際のスタック構成とバックアップの保存場所を記録します。別の再作成でも手探りの手動作業なしに同じ永続データを参照できて、初めてインシデントは解決したといえます。
おすすめ商品
サポートとヒント
もっと読む
ライブTV録画の容量・保存期間・クリーンアップガイド
実際の録音を測定し、ヘッドルームを確保し、経過時間と容量の制限を組み合わせ、ストレージが満杯になる前に最も古い対象プログラムが削除されることを確認する。
データベース復元後のホームメディアメタデータ復旧ワークフロー
復元した状態を保護し、メディアの識別情報とパスを確認してから、メタデータを広範囲に変更する前に、パイロットライブラリで不足しているアートワークや一致項目を修復します。
オーディオ、ビデオ、字幕のJellyfinクライアント互換性チェックリスト
代表的なファイルを一度に1つの変数だけテストし、すべてのクライアントについて、ダイレクトプレイ、リマックス、音声変換、動画トランスコード、または失敗を記録します。
