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

WebUIのセキュリティを無効にせずにZimaOSへqBittorrentをインストールする

A July 2025 thread where the App Store pull failed, IceWhale suggested testing ZimaOS 1.4.2 beta, and the user eventually installed LinuxServer.io qBittorrent manually. The historical workaround disabled WebUI security checks, which should not be carried forward as a default configuration.

2025年7月の元スレッドは、qBittorrentのApp Storeインストール失敗から始まり、LinuxServer.ioコンテナを手動でインストールする形で終わりました。このページの以前の短い説明では、「プルに失敗した」から「LinuxServerを使う」へと急ぎすぎていました。スレッド全体には重要なバージョンに関する寄り道があります。IceWhaleは、アプリのインストール動作が改善されていたため、ユーザーにZimaOS 1.4.2 beta1のテストを依頼しましたが、ベータ版のインストールによってユーザーのGTX 1070に関する新たなGPU問題が発生し、ユーザーは最終的に1.4.1へ戻りました。

手動でインストールしたqBittorrentコンテナは元のユーザーにとって十分に機能しましたが、当時のWebUI回避策では、Host Header ValidationとCSRF保護が無効化されていました。現在のインストールで、これをデフォルトの修正方法として引き継ぐべきではありません。

最初の障害はイメージのプル問題だった

Dockerイメージのプルでアクセス拒否エラーが表示されているZimaOS qBittorrentのインストールダイアログ
元の問題は、qBittorrentが起動することさえできる前に発生していました。設定されたアプリケーションイメージをプルできなかったのです。

イメージのプルエラーは、起動後にクラッシュするコンテナとは異なります。トラブルシューティングの対象は、イメージ参照、レジストリへのアクセス、App Storeの定義、またはZimaOSのアプリインストール層です。

IceWhaleはZimaOS 1.4.2 Beta1を提案

Zima-Giorgioは、当時の最新バージョンである1.4.2 beta1を試すようユーザーに依頼しました。このリリースではアプリのインストール体験が改善されており、問題を解決できる可能性があったためです。アップデートが自動的に表示されなかったため、Giorgioはその当時のベータ版向けに公式のオフラインアップデート手順を案内しました。

これらのコマンドは2025年のプレリリースビルド向けであり、現在のサーバーで再利用すべきではありません。歴史的な意味は、IceWhaleがApp Storeからのプル失敗をZimaOSのバージョンに関連する可能性がある問題として扱ったことです。

ベータ版によってユーザーに別の問題が発生

ユーザーはベータ版をインストールしましたが、ベータ版がGTX 1070 GPUを無視したという本人の説明により、後から1.4.1に戻しました。これは、1つのアプリを修復するためだけにベータ版へアップグレードする場合、サーバーの他の部分についてもリグレッションチェックを行うべき理由を示しています。

現在のシステムでは、特定のサポート上の理由でプレリリース版をテストする必要がない限り、現行の安定版ZimaOSを使用してください。

その後、ユーザーはLinuxServer.ioのqBittorrentイメージをインストールしました

現在のLinuxServer.io qBittorrentでは、 lscr.io/linuxserver/qbittorrent永続化およびネットワーク関連の主な設定は次のとおりです。

  • /config qBittorrentの設定用。
  • コンテナにマッピングするホスト側のダウンロードフォルダー。
  • ファイル所有権のためのPUIDとPGID。
  • WebUIポート。
  • TCPおよびUDPのBitTorrentリッスンポート。

2025年の設定を記憶だけで再構築するのではなく、現在のLinuxServer.io qBittorrentコンテナ設定を使用してください。

WEBUI_PORTとDockerのポートマッピングを同期させる

現在のイメージでは通常、WebUIはポート8080で提供されます。別のホストポートを使用する場合は、そのホストポートをコンテナのサービスにマッピングできます。内部WebUIポート自体を変更する場合、LinuxServer.ioでは WEBUI_PORT 環境変数とDockerのポートマッピングを一致させてください。

WebUIポートの不一致により、認証やセキュリティヘッダーの問題に見える接続失敗が発生することがあります。

起動ログに記載された一時パスワードを使用する

ソースでは、初回パスワードがログで確認できることを正しく指摘していました。現在のLinuxServer.ioの動作では、コンテナの admin 起動時のアカウント。

qBittorrentコンテナのログを開き、初回ログインには一時パスワードを使用して、WebUIからすぐに恒久的なパスワードを設定してください。

デフォルトでHostHeaderValidationとCSRFProtectionを無効にしない

過去のソースでは、次のように追加されていました。

WebUI\HostHeaderValidation=false
WebUI\CSRFProtection=false

qBittorrentの設定ファイルに追加するよう案内しました。これによりアプリケーションは動作するように見えたものの、これらのオプションはブラウザーに対するセキュリティチェックを意図的に弱めます。

現在のインストールでは、まず正しいポート、WebUI URL、リバースプロキシのヘッダー、認証設定を解決してください。WebUIアクセスの問題に対する標準的な回答を「CSRFを無効にする」にしないでください。

リバースプロキシを使用している場合は、適切に設定する

ホストヘッダーエラーは、WebUIが想定していないホスト名やプロキシを介してアプリケーションにアクセスした場合によく発生します。通常の正しい対処は、すべての検証をグローバルに無効にすることではなく、プロキシとqBittorrentのWebUI設定を一貫して構成することです。

WebUIのトラフィックとBitTorrentのピアトラフィックでは異なるポートを使用する

ブラウザーでqBittorrentを管理するために使用するポートは、着信ピア接続に使用するポートとは異なります。選択したトレントのリスニングポートをTCPとUDPで公開し、qBittorrent自身のリスニングポート設定を一致させてください。

サーバーがNATの背後にあり、着信ピア接続が必要な場合、ルーターまたはVPNの設計はDockerのポートマッピングとは別の判断事項です。

ダウンロード先を実際のZimaOSストレージにマッピングする

大容量のトレントを使い捨てのコンテナレイヤーや小容量のシステムディスク内に蓄積させないでください。ダウンロードディレクトリを目的のZimaOSストレージ領域にマッピングし、大容量のダウンロードを開始する前に、コンテナユーザーがそこに書き込めることを確認してください。

コンテナを再作成する前に/configを保持する

qBittorrentの環境設定、カテゴリ、パス、アプリケーション状態は、永続構成ディレクトリに保存されます。イメージを変更したり、App Storeのデプロイメントをカスタムコンテナに置き換えたりする前に、バックアップしてください。

ZimaOS上のqBittorrentに関するFAQ

元の問題はqBittorrentのクラッシュでしたか?

いいえ。App Storeのインストールは、Dockerイメージのプル段階で失敗しました。

ユーザーがベータ版からZimaOS 1.4.1に戻したのはなぜですか?

ベータ版ではGTX 1070が期待どおりに処理されなかったと報告されました。

最初のqBittorrentパスワードはどこから取得されますか?

現在のLinuxServer.ioコンテナでは、起動ログに一時的な管理者パスワードが表示されます。

WebUIを動作させるために、CSRF保護を無効にする必要がありますか?

デフォルトのアプローチとしては適切ではありません。まず現在のポート、プロキシ、ホスト名、認証の設定を修正してください。