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

外付けBtrfs SSDでのqBittorrentのアクセス権拒否:パスをマッピングし、UID/GIDを確認して、rootを避ける

An October 2025 thread where qBittorrent mapped /media/SSD-1TBStorage/Downloads to /downloads but could not create /downloads/incomplete. The user tried UID/GID 1000, chown 1000:1000, and chmod 775. The only reply claimed the ZimaOS admin UID was different and suggested root as a test, but the original poster never confirmed a final fix.

この情報源から明確に分かるのは、qBittorrent がマッピングされた外部の Btrfs フォルダーには到達できたものの、プロセスがその中に incomplete サブディレクトリを作成できなかったということです。エラーは「パスが見つからない」ではなく、Permission Denied(権限が拒否されました)でした。そのため、最も有力なトラブルシューティングの対象は、ファイルシステム上のユーザー識別情報と権限です。

このスレッドから、恒久的な解決策が証明されたわけではありません。唯一の返信では、その ZimaOS システムに UID 1000 が存在しないと指摘し、コンテナを root として実行してテストすることを提案していました。元の投稿者は、成功した結果を報告していません。したがって、qBittorrent を root として実行することは、限定的な診断手段にすぎず、推奨される最終構成として扱うべきではありません。

ボリュームマッピングは明示されていた

情報源では、次のようにマッピングされていました。

/media/SSD-1TBStorage/Downloads  →  /downloads

qBittorrent 内では、アプリケーションが次の場所を作成しようとしていました。

/downloads/incomplete/...

エラーが権限拒否だったことから、マッピングは存在し、コンテナはホストのファイルシステムに到達できていた可能性が高いです。

ホスト側フォルダーにはグループの書き込み権限があった

ユーザーは次の内容を示していました。

drwxrwxr-x 1 1000 samba /media/SSD-1TBStorage/Downloads

また、コンテナは UID/GID 1000 で実行されていると説明していました。さらに、chown -R 1000:1000chmod -R 775 も試していました。

エラーが返されたという事実は、実際の実行時の識別情報、親ディレクトリへのアクセス、マウントの動作、または実効権限のいずれかについて、前提が不完全だったことを示しています。

フォーラムの返信だけを根拠に ZimaOS の UID を固定しない

コミュニティの回答者は、最初の ZimaOS ユーザーには UID 1000 ではなく UID 999 が使われていると述べていました。ただし、それがあるビルドで正しかったとしても、ユーザー ID はプラットフォームやバージョンによって異なる場合があり、qBittorrent コンテナが別の PUID/PGID 識別情報を使用している可能性もあります。

推測で決めず、現在のコンテナ設定とプロセスの実際の識別情報を確認してください。

root として実行すれば権限層を確認できるが、恒久的な設定にはしない

コンテナが UID 0 で実行した場合にのみ動作するなら、マッピング先のパスが通常のアプリケーション識別情報を拒否していることを強く示唆します。ただし、qBittorrent を永久に root で実行すべきという意味ではありません。

Web やネットワークからの入力を受け取るダウンローダーには、必要なファイルシステム権限だけを与えるべきです。

ホスト側パスのすべての親ディレクトリを確認する

最終的な Downloads ディレクトリに書き込み権限があっても、コンテナの識別情報が親ディレクトリのいずれかを通過できなければ十分ではありません。最後のディレクトリのモードビットだけでなく、完全なパスと ACL を確認してください。

Btrfs は使用されていたが、原因が Btrfs だとは証明されていない

SSD には Btrfs が使用されていましたが、通常の Unix の所有権と権限は引き続き適用されます。このスレッドには、Btrfs 固有のバグ、サブボリュームポリシー、または読み取り専用マウントがエラーの原因だったことを証明する情報はありません。

ファイルシステムの種類を原因と決めつける前に、マウントされたファイルシステムの状態を確認してください。

現在の ZimaOS ではアプリのボリュームマッピングが明示される

IceWhale の現在のドキュメントでは、ホスト側とコンテナ側のパスが説明されており、アプリ設定からアプリのストレージマッピングを編集できます。

所有権を変更する前に、現在の ZimaOS の Docker パスモデルを確認してください。

qBittorrent 専用のダウンロードフォルダーを使用する

メディア全体やバックアップ用ボリューム全体ではなく、専用に用意したダウンロード/ステージングフォルダーへの書き込み権限を qBittorrent に与えてください。その後、Sonarr や Radarr が管理された権限のもとで、完了したファイルをインポートまたは移動できます。

より安全な恒久的権限設定の手順

  1. ホスト側からコンテナ側への正確なマッピングを確認します。
  2. qBittorrent コンテナの実際の UID/GID/PUID/PGID を確認します。
  3. ホスト側フォルダーと親ディレクトリの権限を確認します。
  4. 小規模な専用テストディレクトリを作成します。
  5. 必要なユーザーまたはグループにのみ書き込み権限を付与します。
  6. アプリを再起動し、合法的な小容量のダウンロードを 1 件テストします。

qBittorrent と Btrfs の権限に関する FAQ

情報源で最終的な修正は確認されましたか?

いいえ。スレッドは、コミュニティからの 1 件の返信の後で終わっています。

Permission Denied は、Docker のボリュームマッピングが存在しないことを証明しますか?

いいえ。通常は、パスには到達できるものの、プロセスが要求された書き込み操作を実行できないことを意味します。

qBittorrent は恒久的に root で実行すべきですか?

いいえ。root での実行は診断テストとして利用できますが、恒久的な修正では、必要最小限のファイルシステム権限を使用すべきです。