Plexでファイルを再生できるのに削除できない場合、権限に問題がある可能性が高いです。読み取り権限と削除・書き込み権限は別の操作です。元のケースでは、メディアはマウントされたファイル共有上にあり、Plexは読み取れましたが、削除時に「ファイルの削除中に問題が発生しました」と表示されました。
投稿者は最終的に、CIFS共有を広範な0777モードとnopermを指定して再マウントし、ディレクトリを書き込み可能にしました。これにより、問題が実効的なマウント／ファイルシステム権限レイヤーにあったことは分かりますが、永続的な設定として推奨できるほど安全な方法ではありません。
コンテナ内の「root」だけでは権限の問題は解決しない
ユーザーは、Plexコンテナがrootとして実行されているように見えたため、ホストのrootアクセス権を付与しました。しかし、DockerコンテナがバインドマウントされたSMB/CIFSファイルシステムにアクセスする際には、ホスト側のマウントに設定された所有者、モード、ACL、マウントオプションが影響します。
別の場所でホストのroot権限を付与しても、CIFSマウントがコンテナ内でどのようにファイル所有権を示すかが自動的に変わるわけではありません。
ファイルの削除には親ディレクトリへの書き込み権限が必要
Unix系ファイルシステムでは、ファイルの削除は主にディレクトリに対する操作です。そのため、マウントされた親ディレクトリがPlexの実効IDから見て書き込み可能でない場合、Plexはメディアファイルを正常に読み取れても削除できません。
実際のコンテナIDをマウント設定と一致させる
コミュニティでは、Plexコンテナのユーザー／グループをホスト側のフォルダー所有者と一致させるよう案内していました。これは長期的に有効な原則ですが、Plexが常に共通のUIDで実行されるとは限りません。
PLEX_UID／PUID／PGIDを変更する前に、現在のコンテナ設定と、CIFSマウント上で示されている実際の所有権を確認してください。
元のケースでは、広範な回避策として0777とnopermを使用した
元の投稿でCIFSをマウントした際のオプションは、次のようなものでした。
file_mode=0777,dir_mode=0777,nopermこれにより、ほぼすべてのローカルIDから共有への書き込みが可能になり、通常のクライアント側権限チェックも無効になります。マウントポリシーがPlexをブロックしていたことを示す証拠としては有用ですが、永続的な修正方法として最初に選ぶべきではありません。
専用のメディアIDまたはグループを優先する
より安全な設計は、Plexが使用するユーザー／グループ、または共有メディアグループがファイルやディレクトリの所有者として表示されるように共有をマウントすることです。書き込み権限は、Plexが削除を必要とする場所に限定して付与してください。
Plexでほとんどのライブラリを読み取り専用にする場合は、特定の管理対象フォルダーだけを書き込み可能にすることを検討してください。
Plexのボリュームマッピングも確認する
Plexはコンテナ内のメディアパスを使用し、ZimaOSはそのパスをホスト側のマウントに対応付けます。現在のIceWhaleのドキュメントでは、このホストとコンテナの関係が説明されています。
所有権を変更する前に、現在のZimaOS Dockerパスモデルを確認してください。
Plex側でもメディアの削除を許可する必要がある
ファイルシステムの権限が正しくても、該当する場合はPlexのライブラリ／サーバー設定で削除を許可する必要があります。コンテナ内からファイルシステムをテストすれば、「Plexの設定」の問題と「OS権限」の問題を切り分けられます。
使い捨て可能なファイル1つでテストする
対象のメディアフォルダーに小さなテストファイルを作成またはコピーし、Plexから見えることを確認してから、Plex経由で削除し、元の共有からも消えていることを確認してください。固有のメディアを最初に削除して、権限変更をテストしないでください。
Plexの削除に関するFAQ
Plexでファイルを読み取れるなら、削除もできることになりますか？
いいえ。削除には、ファイルを含むディレクトリへの書き込み権限が必要です。
元のケースではchmod／マウントモード0777で解決しましたか？
非常に制限の緩いCIFS再マウント後に成功したとユーザーは報告していますが、最小権限の設計としては推奨されません。
ホストのrootアクセス権だけで、PlexのSMB削除問題は解決しますか？
いいえ。実効的なCIFSマウントの所有権／モードと、コンテナのIDによって書き込み動作は決まります。
