アプリの設定で別のHDDを選択した後も、qBittorrentがZimaOSのシステムドライブにダウンロードを保存している場合は、qBittorrent自体の内部でどのパスを入力したかを確認してください。2025年11月のIceWhaleコミュニティスレッドでは、セカンダリドライブはすでにqBittorrentコンテナーにマウントされていましたが、ユーザーはZimaOSホストパスをDockerコンテナーパスの代わりに入力していました。
確認された解決策は単純でした：次を使用します /downloads ZimaOSのホストパス（たとえば）ではなく、qBittorrent内で /media/GERAL/downloadsPUID/PGIDを次の値に変更しても 0/0 元のケースでは解決しませんでした。パスを修正すると解決し、元の投稿者もその後ダウンロードが機能したことを明確に確認しています。
核心的な違い：ホストパスとコンテナーパス
Dockerボリュームのマッピングには2つの側があります：
ホストパス:コンテナーパス例：
/media/GERAL/downloads:/downloadsZimaOSには左側が見えます。qBittorrentはコンテナー内で動作するため、通常は右側を使用します。
qBittorrent内での正しい設定：/downloads
qBittorrent内での誤った設定： /media/GERAL/downloads元のユーザーが設定していた内容
/downloads.PUIDとPGIDを変更してもこのケースが解決しなかった理由
コミュニティからの最初の返信では、別の方法を試すことが提案されました PUID/PGID values, including 0/0値（次を含む）
。元の投稿者はそれを試しましたが、うまくいかなかったと報告しています。
これは重要です。なぜなら、この事例を権限の問題と区別できるからです。root権限があっても、マッピングされていないホストパスが正しいコンテナーパスになるわけではありません。
現在のLinuxServer版qBittorrentも同じパターンを使用
現在のLinuxServer版qBittorrent Dockerドキュメントでは、次を使用しています：/path/to/downloads:/downloads /downloads を定義し、
コンテナー内のダウンロード先として使用します。これはコミュニティで報告された修正方法と完全に一致します。
LinuxServerのqBittorrent Dockerドキュメント
- ダウンロードフォルダーの修正方法
- ZimaOSでqBittorrentアプリの設定を開きます。
- ダウンロードボリュームのマッピングを確認します。
- コンテナー側が次のような安定したパスになっていることを確認します：
/downloads. - Dockerのマッピングを変更した場合は、アプリを保存して再起動します。
- qBittorrentのWebUIを開きます。
- ツール → オプション → ダウンロードに移動します。
- デフォルトの保存先を次に設定します：
/downloadsまたは次のようなサブフォルダー/downloads/complete. - 小さなテスト用トレントを開始し、データがどの物理ドライブに保存されるか確認してください。
PUID/PGIDの権限が重要になる場合
もし /downloads は正しいですが、qBittorrentのログには 権限が拒否されましたを設定し、その後、所有者と権限を確認します。LinuxServerのイメージは PUID および PGID 特にホストのバインドマウント権限について。
それは元のスレッドとは別の障害です。まずパスが正しいかを診断し、次に権限を確認してください。
ZimaOS版qBittorrentのダウンロードフォルダーに関するFAQ
なぜqBittorrentは引き続きZimaOSのシステムドライブを使用するのですか？
元の事例では、qBittorrentにマウントされたコンテナーパスではなく、ホストパスが設定されていました。
元のスレッドで問題を解決したパスは何ですか？
/downloads。投稿者は動作したことを確認しました。
PUIDとPGIDを0に設定すべきですか？
この問題には当てはまりません。元の投稿者はそれを試しましたが、うまくいきませんでした。まず正しいコンテナーパスを使用してください。
