The source qBittorrent problem had two layers. First, qBittorrent must save to a path that exists inside the container. Second, the qBittorrent process must have write permission to the host folder behind that container path. The user had already solved the mapping layer—the folder was visible—but the execution log still showed Permission Denied.
元のqBittorrentの問題には2つの側面がありました。まず、qBittorrentはコンテナ内に存在するパスへ保存する必要があります。次に、qBittorrentプロセスには、そのコンテナパスの背後にあるホストフォルダーへの書き込み権限が必要です。ユーザーはすでにマッピングの問題を解決しており、フォルダーは表示されていましたが、実行ログには依然としてPermission Deniedと表示されていました。 コミュニティの修正では、専用のダウンロードフォルダーを作成し、非常に広範な chmod -R 777 777 簡単な権限テストとして使用しました。元の投稿者は、その後ダウンロードが機能したことを確認しました。この結果から、失敗の原因が書き込み権限の問題だったことは証明されますが、
現在のシステムで恒久的な推奨設定にすべきではありません。
を使用する必要があります。.使用されていたのは次の設定です。
-
ホスト:
/media/Main Storage/Media/Movies -
コンテナ:
を使用する必要があります。
/Movies-TV qBittorrent内では、保存先パスに/Movies-TV/...
マッピングが機能したことはパスの可視性で確認でき、書き込みができなかったことはPermission Deniedで確認できました。
とは異なります。ユーザーのqBittorrent実行ログには、次の内容が報告されていました。 Permission Deniedこれは No such file or directory:
- No such file/directory: マッピングまたはパスが間違っている可能性があります。
- Permission denied: コンテナはパスにアクセスできますが、そこへ書き込めません。
専用のダウンロードフォルダーなら、適切な権限を設定しやすい
コミュニティでは、次のようなサブフォルダーを作成しました。
/media/Main Storage/Media/Movies/qbittorrent-downloadsqBittorrentのコンテナ側の保存先を次のように設定します。
/Movies-TV/qbittorrent-downloadsダウンローダーが必要とするのが1つのステージングディレクトリだけなら、メディアツリー全体への書き込み権限を与えるよりも、こちらのほうが適切です。
chmod 777 は診断用の近道であり、最終的に適切な権限モデルではない
コミュニティの返信では再帰的な chmod 777 元の投稿者が問題の解決を確認しました。これは因果関係を示していますが、誰でも書き込み可能な権限では、ローカルのすべてのプロセスIDがそのディレクトリに書き込めてしまいます。
より安全な恒久的な解決策は、qBittorrentコンテナの実行時UID/GIDを特定し、そのユーザーまたはグループに必要な書き込みアクセス権だけを付与することです。
所有権を変更する前に確認する
変更前に、フォルダーの所有者・グループとモードを確認するなど、読み取り専用のチェックが役立ちます。qBittorrentが設定可能なPUID/PGIDで実行される場合は、それらの値をダウンロードディレクトリへの書き込み権限を持つホストグループに合わせます。
共有メディアライブラリ全体の所有権を再帰的に変更するのは避け、書き込み可能にする必要があるフォルダーだけを変更します。
現在のZimaOSではアプリボリュームのパスが明示されています
現在のIceWhaleのドキュメントでは、App Storeのアプリケーションはコンテナ内で実行され、重要なフォルダーは実際のホストストレージにマッピングされると説明されています。これらのマッピングはアプリの設定から確認・編集できます。
権限を変更する前に、現在のZimaOS Dockerパスモデルを使用します。
ダウンロード用ステージングフォルダーと最終メディアライブラリを分離する
一般的な構成は次のとおりです。
- qBittorrentは専用のダウンロードフォルダーに書き込みます。
- Sonarr/Radarrなどの整理ツールが完了したファイルをインポートします。
- Jellyfin/Plexは最終的なメディアライブラリを読み取ります。多くの場合、読み取り専用です。
これにより、各アプリケーションに必要なアクセス権だけを与えられます。
まずは小さなダウンロード1件でテストする
マッピングまたは権限を変更した後：
- qBittorrentを再起動します。
- 保存先のパスがコンテナ内で解決されることを確認します。
- 小さな合法テストファイルをダウンロードします。
- 実行ログを確認します。
- ファイルが意図したホストストレージに表示されることを確認します。
qBittorrentのダウンロード先に関するFAQ
元のボリュームマッピング自体が間違っていたのでしょうか？
コミュニティでは、表示もパスも正しいと結論づけられました。残っていたエラーは書き込み権限でした。
chmod 777で元のケースは解決しましたか？
はい。元の投稿者も成功を確認しています。ただし、推奨される恒久的な権限設定ではなく、広範な診断用の近道として扱うべきです。
qBittorrentは内部でどのパスを使用すべきですか？
ZimaOSのボリュームマッピングで定義されたコンテナ側のパス、たとえば /Movies-TV/qbittorrent-downloads.
