データディレクトリの移動後にJellyfinの権限を復元する方法

Jellyfinのデータディレクトリを移動した後は、移動したファイルの所有者を、実際にJellyfinを実行しているIDに合わせ、コンテナまたはサービスが意図したパスを参照していることを確認して、権限を元に戻してください。chmod -R 777から始めてはいけません。

移動によって、数値の所有者、継承ACL、マウントオプション、SELinuxラベル、または再作成したコンテナで使用されるUID/GIDが変わることがあります。この順番で各層を診断し、Jellyfin専用データだけを修正してからサーバーを起動し、データベース、メタデータ、バックアップ、スケジュールされたタスクへの書き込みを確認してください。メディアライブラリの権限に手を加えるのはその後です。

新しいパスとJellyfinの実行時IDを確認する

バックグラウンドでの書き込みと確認作業が競合しないよう、移動したアプリケーションデータを修復する前にJellyfinを停止してください。新しいホストパス、コンテナまたはサービス内でJellyfinから見えるパス、実行中のJellyfinのIDのUID/GIDを確認します。

Jellyfinの移行ガイドでは、Jellyfinユーザーのuidとgidを特定し、移行中も想定どおりのパスを維持することを明確に推奨しています。Jellyfin移行時のUID/GIDに関するガイド

コンテナが間違ったホストディレクトリを参照している場合は、まずマウントを修正してください。権限を変更しても、Jellyfinが空のフォルダに誘導されるパスマッピングの問題は解決できません。また、その空のパスを使って起動すると、新たに別のデータツリーが作成される可能性があります。

変更前に所有者、モードビット、ACLを確認する

移動したディレクトリと、データベース、設定、メタデータ、ログの各サブディレクトリのサンプルについて、数値の所有者とグループを確認します。親ディレクトリの実行権限と、移動先のファイルシステムから継承された可能性のあるACLエントリも確認してください。

NASへの移動により、特にSMB、NFS、コンテナを使用している場合は、IDや権限のモデルが変わることがあります。ZimaSpaceの移動後の権限診断では、マウントが見えていても、コンテナプロセスにUID/GIDによるアクセス権限が必要な理由を説明しています。

不一致を正確に説明できるまでは何も変更しないでください。所有者が違う、グループアクセスがない、親ディレクトリを通過できない、予期しないACLがある、読み取り専用でマウントされている、のいずれなのかを特定します。その説明に基づいて、安全に修復できる最小限の範囲が決まります。

Jellyfin専用のアプリケーションデータだけ所有権を戻す

移動したJellyfinのデータディレクトリをJellyfinのサービスアカウントが所有する想定であれば、そのアプリケーションデータツリーの所有者とグループを本来の設定に戻してください。Jellyfinがそれらのファイルを管理する必要が本当にない限り、無関係な共有メディアの所有権はそのままにしてください。

Jellyfinの移行ドキュメントでは、移動後にJellyfinのデータディレクトリの所有者を修正する方法が説明されています。移行後の所有者の修正これはアプリケーションデータに限定した操作として扱い、NAS共有全体の所有権を再帰的に変更する理由にしないでください。

所有権を修正した後、もう一度サンプルを確認し、専用のテスト用サブディレクトリに対してJellyfinの実行ユーザーとして非破壊の書き込み可能性チェックを実行してください。書き込みが引き続き拒否される場合は、chmodによる変更を追加せず、次にACL、マウントモード、またはセキュリティラベルを調べてください。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

コンテナのマウントモードとセキュリティラベルを確認する

ホスト上で正しい所有者が設定されていても、バインドマウントが読み取り専用の場合、実行ユーザーが変更された場合、またはホストのセキュリティシステムがパスをブロックしている場合は、コンテナ内で失敗することがあります。現在のコンテナ定義を最後に正常に動作したものと比較してください。

Jellyfinのコンテナガイドには、明示的なUID/GIDでの実行、読み取り専用のメディアマウント、SELinux環境向けのPodman再ラベルオプションが記載されています。コンテナの権限と再ラベル付け これらの設定は、通常のUnixモードビットから許可されているように見える操作を制限することがあります。

確認できたレイヤーだけを変更してください。Jellyfinが書き込む必要がある場合はアプリケーションデータのマウントを書き込み可能にし、正しい実行時UID/GIDに戻すか、そのマウントにプラットフォームに適したラベルを適用してください。その後、コンテナを1回だけ再作成し、内部から同じパスを再確認してください。

Jellyfinを起動し、データベースとデータディレクトリへの書き込みを確認する

Jellyfinを起動し、起動ログを確認してください。セットアップウィザードや空のライブラリではなく、既存のサーバー状態が開かれることを確認し、データベース、設定、メタデータ、ログに関する権限エラーがないか確認してください。

起動後に通常のダッシュボードが表示されたら、テスト環境でのスケジュールタスクやメタデータ操作など、Jellyfinが管理する状態に書き込むリスクの低い操作を1つ実行し、権限エラーなしで想定どおりにファイルまたはデータベースの状態が変わることを確認してください。

Jellyfinをもう一度再起動してください。新規起動後に同じデータディレクトリが問題なく開けた場合にのみ、修復完了とみなします。1回だけ正常に動作しても、再作成時に再発するマウントまたは初期化の問題が隠れている可能性があります。

広範囲な変更をロールバックし、正確な証拠を添えて上位サポートに引き継ぐ

すでに広範囲にわたる再帰的な権限変更を適用してもサーバーが正常に動作しない場合は、アクセス権をさらに広げないでください。可能であれば、記録してある所有権設定またはバックアップから復元し、実行時のユーザーとパスの不一致を個別に確認してください。

コンテナ化されたサーバーでは、現在のマウント元、マウント先、UID/GID、グループ、セキュリティコンテキストを、保存してある動作確認済みの定義と比較してください。ネイティブインストールでは、サービスの実行ユーザーと、保存先ファイルシステムのマウントおよびACLの挙動を比較してください。目的は、説明可能な権限モデルを一つ確立することです。

Jellyfinが元のデータベースを開き、自身のデータディレクトリに書き込み、選択したバックグラウンド操作を完了し、再起動後も正常に動作することを確認したら、作業を終了してください。いずれかの確認に失敗した場合は、数値の所有者情報、ACLの出力、マウントオプション、実行時のUID/GID、および最初に発生した権限関連のログエラーがあればその内容を添えて、上位サポートに引き継いでください。