データディレクトリ移動後にJellyfinのアクセス権を復元する方法
Jellyfinのデータディレクトリを移動した後は、移動したファイルを実際にJellyfinを実行しているユーザーに合わせ、コンテナまたはサービスが意図したパスを参照していることを確認して、権限を復元します。最初からchmod -R 777を実行しないでください。
移動によって、数値の所有者、継承されたACL、マウントオプション、SELinuxラベル、または再作成したコンテナで使用されるUID/GIDが変わることがあります。まずその順番で各層を診断し、Jellyfinが所有するデータだけを修正してからサーバーを起動し、メディアライブラリの権限に触れる前に、データベース、メタデータ、バックアップ、スケジュールタスクへの書き込みを確認します。
新しいパスとJellyfinの実行時ユーザーを確認する
移動したアプリケーションデータを修復する前にJellyfinを停止し、バックグラウンドの書き込みが調査と競合しないようにします。新しいホストパス、コンテナまたはサービス内からJellyfinが認識するパス、そして実行中のJellyfinユーザーのUID/GIDを確認します。
Jellyfinの移行ガイドでは、Jellyfinユーザーのuidとgidを確認し、移行中も想定されるパスを維持することを明確に推奨しています。Jellyfinの移行に関するUID/GIDガイド
コンテナが誤ったホストディレクトリを参照している場合は、まずマウントを修正します。権限を変更しても、Jellyfinを空のフォルダーへ送るパスマッピングの問題は解決できません。その空のパスを使って起動すると、新しいデータツリーが別に作成される可能性があります。
変更前に所有権、モードビット、ACLを調査する
移動したディレクトリと、そのデータベース、設定、メタデータ、ログの各サブディレクトリのサンプルについて、数値の所有者とグループを一覧表示します。親ディレクトリの実行権限と、移動先ファイルシステムから継承された可能性のあるACLエントリも確認します。
特にSMB、NFS、またはコンテナが関係する場合、NASへの移動によって異なるユーザー識別情報や権限モデルが導入されることがあります。ZimaSpaceの移動後の権限診断に関する記事では、マウントが見えていても、コンテナプロセスのUID/GIDによる認証が回避されるわけではない理由を説明しています。
不一致を正確に説明できるようになるまで、何も変更しないでください。所有者が誤っているのか、グループアクセスが不足しているのか、親ディレクトリの通過がブロックされているのか、想定外のACLがあるのか、読み取り専用マウントなのかを特定します。その内容によって、最小限で安全な修復方法が決まります。
Jellyfinが所有するアプリケーションデータだけ所有権を復元する
移動したJellyfinデータディレクトリをJellyfinサービスアカウントが所有する想定であれば、そのアプリケーションデータツリーの所有者とグループを本来の状態に戻します。Jellyfinが実際に管理する必要がない限り、共有メディアの所有権は変更せずに維持します。
Jellyfinの移行ドキュメントには、移動後にJellyfinデータディレクトリの所有権を修正する手順が含まれています。移行後の所有権修正 これは対象を絞ったアプリケーションデータ操作として扱い、NAS共有全体の所有権を再帰的に取得する理由にはしないでください。
所有権を修正した後、もう一度サンプルを調査し、Jellyfinユーザーとして専用のテストサブディレクトリに対する非破壊的な書き込み可能性チェックを実行します。それでも書き込みが拒否される場合は、chmodの変更を追加せず、次にACL、マウントモード、またはセキュリティラベルを調査します。
コンテナのマウントモードとセキュリティラベルを確認する
ホスト上の所有者が正しくても、バインドマウントが読み取り専用である場合、実行時ユーザーが変わった場合、またはホストのセキュリティシステムがパスをブロックしている場合は、コンテナ内で失敗する可能性があります。現在のコンテナ定義を、最後に正常動作していた定義と比較します。
Jellyfinのコンテナガイドでは、明示的なUID/GIDでの実行、読み取り専用のメディアマウント、SELinux環境向けのPodman再ラベルオプションを示しています。コンテナの権限と再ラベル付け これらの制御によって、通常のUnixモードビットでは許可されているように見える操作が制限されることがあります。
確認できた層だけを変更します。Jellyfinが書き込む必要がある場合はアプリケーションデータのマウントを書き込み可能にし、正しい実行時UID/GIDを復元するか、そのマウントにプラットフォームに適したラベルを適用します。その後、コンテナを一度だけ再作成し、コンテナ内部から同じパスを再確認します。
Jellyfinを起動し、データベースとデータディレクトリへの書き込みを確認する
Jellyfinを起動し、起動ログを追跡します。セットアップウィザードや空のライブラリではなく既存のサーバー状態を開いていることを確認し、データベース、設定、メタデータ、ログに関する権限エラーがないか確認します。
起動後に通常のダッシュボードが表示されたら、テスト環境でのスケジュールタスクやメタデータ操作など、Jellyfinが所有する状態に書き込む低リスクの操作を1つ実行し、権限エラーなしに想定したファイルまたはデータベースの状態が変化することを確認します。
もう一度Jellyfinを再起動します。同じデータディレクトリが新しい起動後にも問題なく開ける場合にのみ、修復が完了したと判断できます。1回のセッションで成功しても、再作成時に再発するマウントや初期化の問題が隠れている可能性があります。
広範な変更を元に戻し、正確な証拠を添えてエスカレーションする
すでに再帰的に広範な権限を適用したにもかかわらずサーバーが壊れたままの場合は、アクセス範囲をさらに広げないでください。可能であれば、記録した所有権またはバックアップから復元し、特定の実行時ユーザーとパスの不一致に戻って調査します。
コンテナ化されたサーバーでは、現在のマウント元、ターゲット、UID/GID、グループ、セキュリティコンテキストを、保存してある正常動作時の定義と比較します。ネイティブインストールでは、サービスユーザーと、移動先ファイルシステムのマウントおよびACLの動作を比較します。目標は、1つの説明可能な権限モデルにすることです。
Jellyfinが元のデータベースを開き、自身のデータディレクトリに書き込み、選択したバックグラウンド操作を完了し、再起動後も動作することを確認できたら終了します。いずれかの確認に失敗する場合は、数値の所有権、ACLの出力、マウントオプション、実行時UID/GID、そして最初に発生した権限関連のログエラーを添えてエスカレーションします。
おすすめ商品
サポートとヒント
もっと読む
Jellyfinでは共有アカウントを1つ使うべきか、それとも家庭内で別々のアカウントを使うべきか？
必要な本人確認、アクセス、ペアレンタルコントロール、復旧の境界に応じて、Jellyfinの家庭用アカウントを選択してください。
作業完了後もJellyfinのメモリ使用量が高いままなのはなぜですか？
Jellyfinプロセスの増加とLinuxキャッシュを切り分け、メモリ使用量が増え続けるか、実際にメモリ圧迫が発生した場合にのみ調査してください。
Jellyfinのストレージ構成が復旧リスクになりつつある兆候
Jellyfinのストレージの役割を監査し、稼働中の状態をバックアップや再構築可能なデータから分離したうえで、復元によってその構成を検証する。
