コミュニティソリューション

ZimaOSでEmbyの自動整理が「アクセス許可がありません」になる

An Emby user on ZimaOS RAID 5 could read a TV library but needed write permission so Auto-Organize could rename and move episodes.

要点:EmbyのAuto-Organizeには、書き込み可能なDockerマウントと書き込み可能なホスト権限の両方が必要です

Embyは読み取り専用アクセスでもメディアライブラリをスキャンできますが、Auto-Organizeではファイルの名前変更、移動、場合によっては削除が必要です。そのためには2つの層で書き込みアクセスが必要です。ZimaOSホストフォルダーをコンテナに読み書き可能としてマウントし、Embyプロセスにホストファイルを変更する権限を与える必要があります。両方を意図的に修正し、再帰的な chmod 777 恒久的な解決策として

手順1:ホストフォルダーが読み書き可能でマウントされていることを確認する

Embyアプリの設定を開き、「Volumes」を確認します。マッピングは概念的に次のようになります。

/media/RAID5/TV  ->  /media/tv

Emby内では、/media/tvを選択します。Embyから左側にあるZimaOSホストパスを直接参照することはできません。Dockerのバインドマウントでは、この2つのパスのモデルについて説明しています。

現在のZimaOSアプリパスは、一般的なApp Storeコンテナに適用されます。

手順2:マウントが読み取り専用でないことを確認する

docker inspect EMBY_CONTAINER

TV/メディアのバインドマウントを探し、読み取り専用としてマークされていないことを確認します。コンテナ内から、実際にマッピングされた保存先に一時ファイルを作成して、安全にテストすることもできます。

docker exec -it EMBY_CONTAINER sh
touch /media/tv/.emby-write-test
rm /media/tv/.emby-write-test

次の場合 touch 失敗する場合、Auto-Organizeも失敗します。

手順3:Embyプロセスとホストの所有権を一致させる

ホストフォルダーとプロセスのIDを確認します。

ls -ld /media/RAID5/TV
ls -ln /media/RAID5/TV
docker exec EMBY_CONTAINER id

次に、そのコンテナに必要な最小限の所有者/グループ権限を付与します。以前の回答では次のコマンドを提案していました。 chown -R 1000:1000ただし、UID 1000がすべてのEmbyイメージで使用されるIDであるとは限りません。まず確認してください。

EmbyのEmby Dockerセットアップは、使用しているイメージの公式リファレンスです。

chmod -R 777を恒久的な修正として使用しない

次の場合 777 この機能が動作するなら、権限の問題であることは確認できています。ただし、すべてのローカルユーザーおよびプロセスに書き込み権限も付与されています。テスト完了後は、より限定的な所有者/グループモデルに戻してください。メディアサーバーの場合、 775 適切なグループを設定するほうが、通常は「全員が書き込み可能」より安全ですが、正確な値はコンテナのID設定方法によって異なります。

ソースと移動先のパスをどちらも書き込み可能にする

自動整理では、受信フォルダーを監視してから、最終的なテレビ番組ライブラリにファイルを移動する場合があります。両方の場所がコンテナ内から見える必要があり、移動先には書き込み権限が必要です。最終ライブラリが読み取り専用だと、最初の名前変更や移動操作までは監視フォルダーが正常に見えることがあります。

RAID 5は権限を制御する層ではありません

RAID 5上にあるメディアだからといって、書き込みが本質的に妨げられるわけではありません。RAIDは冗長性とブロックストレージを制御し、Dockerのバインドマウントとファイルシステムの所有権がアプリケーションのアクセスを制御します。コンテナが書き込みエラーを返したからといって、アレイを再構築しないでください。 権限が拒否されました.

ZimaOSのデータ移行は、Embyコンテナの作成後にメディアパスを移動した場合に役立ちます。

アプリを再作成する前にEmbyの設定をバックアップする

Embyを再インストールすると、根本的なメディアフォルダーの問題が解決しないまま、コンテナの設定が変更されることがあります。再作成する前に、永続化されたEmbyの設定を保持し、すべてのボリュームマッピングを記録してください。ZimaOSのバックアップで復旧レイヤーを保護できます。

より安全な権限トラブルシューティングの手順

  1. ホスト側のパスが存在することを確認します。
  2. コンテナ内のパスが対象のパスに対応していることを確認します。
  3. マウントが読み書き可能であることを確認します。
  4. コンテナのUID/GIDを確認します。
  5. ホスト側の所有者とグループを確認します。
  6. 一時ファイルを1つテストします。
  7. その後で初めて、自動整理をテストしてください。

ZimaOSアプリの要件では、App Storeのストレージモデルについて詳しく説明しています。

よくある質問

Embyではファイルを再生できるのに、整理できないのはなぜですか?

再生には読み取り権限だけが必要です。自動整理には、ファイルの作成、名前変更、移動、削除の権限が必要です。

フォルダーの所有者を1000:1000に変更すべきですか?

実行中のEmbyプロセスが実際にそのUID/GIDを使用している場合に限ります。まずコンテナのIDを確認してください。

chmod 777は安全ですか?

必要な場合に限り、短時間の診断目的で使用してください。恒久的な権限モデルとしては範囲が広すぎます。

RAID 5にするとEmbyは読み取り専用になりますか?

いいえ。RAIDレベルとアプリケーションのファイル権限は別の層です。

Emby内にはどのパスを追加すればよいですか?

Dockerボリュームのマッピングにあるコンテナ側のパスを使用してください。ZimaOSの「ファイル」に表示されるホスト側のパスは使用しないでください。