エラー フォルダー '/tv/' はユーザー 'abc' によって書き込み可能ではありません これは、Sonarrからマウントされたディレクトリが見えていても、コンテナ内で実行されているプロセスにはそこへ書き込む権限がないことを意味します。同じ問題は、Radarrで映画ルートフォルダーのエラーとして発生することもあります。
2025年7月のIceWhale Communityの事例では、両方のアプリケーションがZimaOS App Storeから提供され、デフォルトの設定を使用していました。 PUID=1000 および PGID=1000ユーザーのメディアフォルダーはRAIDストレージプールにありました。IceWhaleのチームメンバーは、両方のIDを次の値に設定することを提案しました。 0また、元の投稿者は、これによりフォルダーが書き込み可能になったことを確認しました。これは重要な事例結果ですが、アプリケーションをroot相当のIDで実行すると、通常必要とされる範囲を大幅に超えるファイルシステムアクセス権が付与されます。現在のLinuxServer.ioのドキュメントでは、代わりにPUID/PGIDをホストディレクトリの所有者またはグループに合わせることが推奨されています。
「フォルダーはユーザー abc によって書き込み可能ではありません」の意味
スレッド内のZimaOS App Storeパッケージでは、LinuxServer形式のSonarrおよびRadarrコンテナが使用されていました。これらのイメージは、通常、内部ユーザーとして表示されるアプリケーションプロセスを実行します。 abc一方、 PUID および PGID その内部プロセスを、ホストファイルシステム上の数値ユーザーIDとグループIDに割り当てます。
ホストディレクトリが別のUID/GIDに属しており、その権限ビットでマッピングされたプロセスの書き込みが許可されていない場合、SonarrやRadarrはマウントを参照できますが、そこにメディアを作成、名前変更、移動、インポートすることはできません。
ZimaOS App Storeの元のマッピング
投稿には、RadarrとSonarrそれぞれの設定スクリーンショットが掲載されていました。アプリケーションから設定済みのホストボリュームは見えていましたが、アプリケーション内でルートフォルダーを作成できませんでした。
SonarrとRadarrのエラー
Sonarrから返された内容：
ルートフォルダーを追加できません
フォルダー '/tv/' はユーザー 'abc' によって書き込み可能ではありません
映画パスについても、Radarr で同様の問題が表示されました。
コミュニティによる修正：PUID=0、PGID=0
IceWhale のチームメンバーが返信しました。
PUID=0
PGID=0元の投稿者は両方の値を 0 に変更し、問題が解決したようだと報告しました。したがって、これは 2025 年 7 月の特定の ZimaOS App Store 構成に対して確認された解決策です。
ただし、UID 0 と GID 0 は Linux では root レベルの ID です。これらの ID で Sonarr または Radarr を実行すると、パスがコンテナにマウントされている場合、アプリケーションが意図したメディアライブラリ以外の広範な場所に書き込める可能性があります。付与されるアクセス権を理解している場合に限り、診断または互換性の回避策として使用してください。
推奨される修正：PUID と PGID をホストストレージの所有権に合わせる
現在の LinuxServer.io の Sonarr および Radarr ドキュメントでは、意図された設計が説明されています。PUID と PGID をホストストレージの所有権に合わせて設定します PUID および PGID マッピングされたボリュームをすでに所有している、または書き込み権限を持つホストユーザー／グループに合わせます。
LinuxServer のガイダンスによると、ホストボリュームの所有 ID とコンテナに指定された ID が一致しない場合に権限の問題が発生します。推奨される設定は次のとおりです。
PUID=1000
PGID=1000UID 1000 と GID 1000 がメディアパスに実際に適している場合に限ります。数値 1000 必ずしも正しいわけではなく、Linux で最初に使われることの多い非 root ユーザー ID にすぎません。
最新の LinuxServer Sonarr ドキュメント と LinuxServer Radarr ドキュメントを確認してください。
ストレージの所有者と権限を確認する方法
ZimaOS のファイルインターフェースに必要な Linux の数値上の所有者・グループ値が表示されない場合は、権限のあるターミナルから実際のホストパスを確認してください。
まず、マッピングされている実際のホストディレクトリを特定します /tv または /movies次に、以下を確認します。
ls -ldn /REAL/HOST/PATH
stat /REAL/HOST/PATH数値の出力から、現在そのディレクトリを所有している UID と GID を確認できます。コンテナ専用パスに対してこれらのコマンドを実行しないでください /tv ホストパスでない限り、ホスト側から
目的のメディア管理アカウントがホスト上で利用できる場合は、次のコマンドでその ID を確認できます。
id USERNAME次に Sonarr/Radarr の PUID および PGID 意図したアクセスモデルに対応する ID に設定します。
コンテナ内で /tv に対して盲目的に chown しない
別のコミュニティ回答では、次のように提案されていました。
sudo chown abc:abc /tv/この助言は、文脈を確認せずにそのまま適用すると危険です。バインドマウントされたディレクトリの所有権は、最終的にはホスト上の数値 ID で表されます。名前 abc LinuxServer コンテナ内には存在しますが、ホスト上で意味のあるアカウントとして存在しない場合があります。所有権を再帰的に変更すると、メディアライブラリ全体に予期せぬ影響を及ぼす可能性もあります。
を使用する前に chown、次の点を確認します。
- 変更対象となる正確なホストパス。
- 目的のホスト UID と GID。
- qBittorrent、SABnzbd、Jellyfin、SMB ユーザーなど、同じファイルへのアクセスが必要な他のサービスがあるかどうか。
- 所有権を変更するよりも共有グループのほうが適切かどうか。
重要な設定をバックアップし、影響を理解するまでは再帰的な権限変更を避けてください。
ARR スタック全体で共有メディアの権限を計画する
Sonarr と Radarr は単独で動作することはほとんどありません。まずダウンロードクライアントがファイルを作成し、次に Sonarr または Radarr がそれらを取り込み、Jellyfin が結果を読み取る場合もあります。すべてのコンテナで関連性のない ID とマウントを使用すると、あるアプリケーションが別のアプリケーションでは変更できないファイルを作成する可能性があります。
より整理された設計では、共有データセットに対して、アプリケーション間で共通のグループまたは互換性のある PUID/PGID マッピングを設定します。LinuxServer も、ダウンロードクライアントと ARR アプリケーションが必要に応じてハードリンクやアトミック移動を使用できるよう、ボリュームパスを綿密に計画することを推奨しています。
たとえば、downloads と media を無関係な個別マウントとして扱う代わりに、ホスト上で単一の共有データツリーを用意すると、権限とパスの一貫性を把握しやすくなります。
/data
├── downloads
├── media
│ ├── movies
│ └── tv正確な ZimaOS のパスはストレージプールによって異なるため、よく確認せずにそのままコピーしないでください。
root ID の回避策が役立つのはどのような場合ですか？
PUID/PGID を次の値に設定する 0 短時間の診断として役立つ場合があります。
- エラーがすぐに消えるなら、コンテナのマウント自体はおそらく正しい状態です。
- 残る問題は、ホスト側の所有権または権限マッピングである可能性が高くなります。
確認できたら、長期的にはコンテナにメディアパスとダウンロードパスに必要な権限だけを付与するのがより安全な目標です。お使いの正確な ZimaOS ストレージモデルで非 root マッピングが現実的でない場合は、root ID が必要な理由を記録し、マウントするディレクトリを慎重に制限してください。
PUIDまたはPGIDを変更した後にアプリを再起動する
PUIDとPGIDは、コンテナの起動時に適用されます。ZimaOSで変更した後は、
- アプリの設定を保存します。
- ZimaOSを通じてSonarr／Radarrコンテナを再起動または再作成します。
- ルートフォルダーの設定をもう一度開きます。
- マウントされたフォルダーの作成または選択をテストします。
フォルダーが書き込み不可のままの場合は、ホストディレクトリの数値所有者とモードを、現在コンテナで使用しているIDと比較してください。
Sonarr／Radarr ZimaOS権限チェックリスト
- ホストのメディアパスがSonarrまたはRadarrにマウントされていることを確認します。
- アプリ内で選択しているのがコンテナパスであることを確認します。
- ホストパスのUID、GID、権限ビットを確認します。
- 現在の値を確認
PUIDおよびPGIDZimaOSアプリの設定で。 - 想定するホストの所有者／グループと一致するIDを優先してください。
- IDを変更したらコンテナを再起動してください。
- PUID/PGID 0は、付与されるrootレベルのアクセス権を理解したうえでのみ使用してください。
- 広範囲に再帰的な設定は避ける
chmod 777または無闇にchown修正方法。 - ダウンロードクライアントとメディアサーバーで、互換性のある共有権限モデルが使用されていることを確認してください。
SonarrとRadarrの権限に関するよくある質問
ユーザーabcとは誰ですか？
abc これは、LinuxServer.ioのコンテナで一般的に使用される内部サービスユーザー名です。PUIDとPGIDによって、そのプロセスがマウントされたボリュームへのアクセスに使用するホスト側の数値IDが決まります。
PUID=1000とPGID=1000ではなぜ失敗するのですか？
これらの値が機能するのは、UID/GID 1000にホストのメディアディレクトリへの必要なアクセス権がある場合だけです。ZimaOSのRAIDディレクトリが別のユーザーまたはグループに属している場合、コンテナから参照はできても書き込みはできないことがあります。
PUID=0とPGID=0で問題は解決しますか？
元のコミュニティ事例では、投稿者が確認したとおり問題が解決しました。ただし、マウントされたファイルシステム内でroot相当のアクセス権も付与されるため、恒久的な構成として自動的に優先すべきではありません。
メディアフォルダーをchmod 777にすべきですか？
デフォルトの修正方法としてはおすすめしません。全ユーザーに書き込み権限を与える設定は広すぎ、実際の所有者の不一致を隠してしまう可能性があります。代わりに、コンテナのIDと共有グループの権限を意図的に一致させてください。
Sonarr、Radarr、ダウンロードクライアントでは、同じPUID／PGIDを使用すべきですか？
共有するファイルやフォルダーについて、常に同一のユーザーIDが必要というわけではありませんが、互換性のある所有者／グループモデルが必要です。一貫した共有グループを使用することは、インポートや名前変更の失敗を避ける一般的な方法です。
