このスレッドで確認された解決策は、qBittorrentのデフォルト保存先をZimaOSホストのパスではなく、Dockerコンテナ内のパス /downloads に設定することでした。 ユーザーはすでにセカンダリHDDを正しくマウントしており、qBittorrentにはホスト側でしか認識できないパスが保存先として指定されていただけでした。
PUID/PGIDをrootに変更しても、元のケースは解決しませんでした。パスを修正すると、元の投稿者はダウンロードが機能したことを明確に確認しています。
元のマッピングの状態
/downloads として正しく利用できる状態でした。 出典：IceWhaleコミュニティフォーラム。重要なマッピングは概念的には次のとおりです。
ホスト: /media/GERAL/Downloads → コンテナ: /downloads
ZimaOSが認識するのは左側です。qBittorrentはDocker内で動作するため、通常は右側を使用する必要があります。
間違っていたパスはqBittorrent内に設定されていた
/media パスを入力していました。 出典：IceWhaleコミュニティフォーラム。qBittorrentのWebUIには /media/GERAL/Downloads が設定されていました。しかし、そのホスト側のパスはコンテナ内のアプリに公開されているパスではありませんでした。
現在のqBittorrentフォルダーガイドでは、同じケースと検証済みの解決方法を説明しています。
rootのPUIDとPGIDで解決しなかった理由
権限とパスの可視性は別の問題です。rootで実行しても、マウントされていないホスト側のパスがコンテナ内に突然表示されることはありません。まずコンテナ内のパスを確認し、正しくマッピングされたパスで Permission denied が返された場合にのみ、所有者や権限を調査してください。
隣接するqBittorrent権限ガイドでは、この2つ目の失敗パターンを解説しています。
現在のDockerイメージでも同じパターンを使用
現在のLinuxServer qBittorrentイメージでは、ダウンロード用ボリュームを /downloads にマウントする設定が案内されています。カスタマイズしたアプリ定義を変更する前に、LinuxServer qBittorrentのドキュメントを確認してください。
結論
ZimaOSが対象ディスクをqBittorrent内の /downloads としてすでにマッピングしている場合は、qBittorrent内で /downloads またはその配下のサブフォルダーを使用してください。そのパスと同じものがコンテナにもマウントされていない限り、ZimaOSのホスト側パスをアプリケーションに貼り付けないでください。
