Jellyfinは、見つからないファイルをなぜ間違った所有者で再作成するのですか？

Jellyfinでは、実行中のサービスIDがディレクトリの所有者と異なる場合や、別のインポートパスで異なるUID/GIDが使われている場合、通常、所有者が誤った状態でファイルが再作成されます。

問題が新しくダウンロードされたアートワークだけに影響するのか、それともJellyfinが書き込むすべてのファイルに影響するのかを確認してください。再帰的な権限コマンドを実行する前に、正常なファイル、新しく作成されたファイル、実行中のコンテナID、バインドマウント先を比較します。目的は、症状を繰り返し修復するのではなく、継承の仕組みを直すことです。

書き込みを実行したIDとパスを特定する

実行中のコンテナのユーザーとグループを確認し、ディスク上のComposeファイルだけに頼らず、実際のバインドマウントを調べます。Jellyfinの設定とキャッシュのパスに書き込み権限があることを確認し、書き込みが不要な場合はメディアを読み取り専用のままにします。段階的な権限チェックにより、ホストからの可視性、コンテナのマッピング、サービスIDを切り分けられます。

ホストではファイルが見えるのにコンテナから見えない場合は、マウントを修正します。コンテナから書き込めるのに所有者が誤っている場合は、IDと継承のテストに進みます。

所有者が誤っているのがインポートされたファイルだけの場合は、インポート元のUID/GIDとumaskをJellyfinのものと比較します。新しいファイルがすべて誤った状態になる場合は、親ディレクトリのデフォルトACLとsetgidの動作を確認します。

umask、グループ、ACL、インポートワーカーを確認する

親ディレクトリのUID/GIDとモードを、ファイルを作成するプロセスと比較します。Jellyfinが後から項目を表示する場合でも、ダウンローダー、スケジュールタスク、サイドカーが別のコンテナを通じて書き込んでいる可能性があります。ツリー全体を変更する前に、補助グループとデフォルトACLを確認してください。

永続的な対策として、全体を誰でも書き込めるようにする再帰的な権限変更は使用しないでください。サービスIDを意図したグループに合わせるか、共同利用が必要なディレクトリだけに共有グループとデフォルトACLを明示的に設定します。

IDを変更した後、正確なインポート経路を通して新しいファイルを1つ作成してテストします。コンテナやサイドカーを再作成する前に作られたファイルだけを見て、修正結果を判断しないでください。

継承を修復し、再作成後に検証する

影響を受けたディレクトリに対して、必要最小限の所有権またはACL変更を適用し、テスト用ファイルを1つ再作成して所有者とモードを確認します。コンテナを再作成し、ホストを再起動した後、同じインポートを繰り返して、デプロイとマウント順序をまたいでも修正が維持されることを確認します。

クリーンな再作成後も所有者が変わる場合、ファイルシステムがPOSIX所有権を無視する場合、または複数のサービスが同じパスを管理しようとしている場合は、さらに調査してください。書き込みに成功したファイルとCompose設定を保持しながら、書き込み元を絞り込みます。

再起動後に所有者が元に戻る場合は、マウントまたはデプロイによって別のIDが適用されています。ファイルシステムツリーを再度変更する前に、正常に動作しているCompose設定を保持してください。

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

再起動と再インポート後の所有権を確認する

コンテナを再作成し、ホストを再起動して、管理対象のテストファイルを1つインポートします。ホストとコンテナの両方から、所有者、グループ、モード、Jellyfinでの可視性を確認します。

新しいファイルが意図したグループを継承し、Jellyfinがワークフローに必要なディレクトリだけを読み書きできる場合は、その修正を維持します。メディアツリー全体に広範な書き込み権限を付与しないでください。

管理対象の再インポート後もファイルシステム、ACLレイヤー、または複数の書き込み元によって所有者が変更される場合は、さらに調査してください。