qBittorrent: Nicht autorisiert auf ZimaOS – Lösung für die WebUI-Anmeldung

Eine schlichte weiße Unauthorized-Seite in qBittorrent weist nicht immer auf dasselbe Problem hin wie die Eingabe eines falschen Benutzernamens oder Passworts. Der IceWhale-Community-Thread beschreibt beide Situationen: Einige Nutzer konnten die qBittorrent-WebUI erst korrekt erreichen, nachdem sie den ZimaOS-Server mit einer expliziten http://-URL geöffnet hatten, während spätere Nutzer zwar den Anmeldebildschirm erreichten, aber nicht wussten, wo das generierte qBittorrent-Passwort gespeichert war.

Der sicherste Ansatz zur Fehlerbehebung besteht daher darin, die Validierung der WebUI-Anfrage von der WebUI-Authentifizierung zu trennen. Stellen Sie zunächst sicher, dass der Browser qBittorrent über die richtige URL und das richtige Protokoll erreicht. Erst nachdem der Anmeldebildschirm geladen wurde, sollten Sie den Administrator-Benutzernamen und das temporäre Passwort untersuchen.

Zuerst die explizite http://-URL testen

Eine Antwort aus der Community vom Februar 2025 berichtete, dass bereits das Hinzufügen von http:// vor die Server-IP die Unauthorized-Seite behoben hat:

http://ZIMAOS_LAN_IP:QBITTORRENT_PORT

Ein anderer Nutzer bestätigte später, dass er dadurch zur qBittorrent-WebUI-Anmeldeseite gelangte.

Verwenden Sie den tatsächlichen hostseitigen qBittorrent-WebUI-Port, der in den App-Einstellungen von ZimaOS angezeigt wird. Wenn die App 8080 direkt bereitstellt, kann die URL beispielsweise so aussehen:

http://192.168.1.50:8080

Gehen Sie nicht davon aus, dass jedes qBittorrent-Paket für ZimaOS denselben Host-Port verwendet.

Warum kann die URL selbst „Unauthorized“ verursachen?

Die qBittorrent-WebUI umfasst neben dem Anmeldeformular weitere Sicherheitsprüfungen. Der aktuelle qBittorrent-Quellcode kann eine Unauthorized-Antwort zurückgeben, wenn die Validierung des Host-Headers oder der Cross-Site-Anfrageschutz eine Anfrage ablehnt.

Das bedeutet, dass sich diese Varianten unterschiedlich verhalten können:

192.168.1.50:8080
http://192.168.1.50:8080
https://192.168.1.50:8080
https://some-dashboard-link.example/...

wenn Browser, Dashboard, Reverse-Proxy, Origin oder Protokoll unterschiedliche Request-Header verursachen. Das Ergebnis aus der Community beweist nicht, dass jede Unauthorized-Seite durch fehlende http://, aber dadurch eignet sich die explizite LAN-URL als erste Diagnosemaßnahme.

Ein privates Browserfenster ist eine Diagnosehilfe, keine vollständige Lösung

Der erste Vorschlag aus der Community war, ein privates Browserfenster zu verwenden. Ein Nutzer berichtete, dass dies einmal funktioniert habe, wodurch das Problem zunächst wie ein Cookie-Problem wirkte. Spätere Tests zeigten jedoch, dass das private Surfen das Problem nicht zuverlässig löste.

Verwenden Sie ein Inkognito-/privates Fenster, um veraltete Sitzungsdaten als Ursache auszuschließen, aber belassen Sie es nicht bei diesem Schritt. Wenn der Fehler erneut auftritt, testen Sie die explizite HTTP-URL und sehen Sie die qBittorrent-Protokolle durch.

Ein späterer Benutzer konnte die qBittorrent-Anmeldeseite aufrufen, nachdem er http:// aber anschließend Kombinationen aus dem ZimaOS-Passwort, einem leeren Passwort und admin. Diese Zugangsdaten stehen nicht unbedingt miteinander in Zusammenhang.

Moderne qBittorrent-Versionen haben das Authentifizierungsverhalten der WebUI beim ersten Start geändert. In der offiziellen Dokumentation zur qBittorrent-Passwortwiederherstellung steht, dass qBittorrent 4.6.1 und spätere Versionen ein temporäres WebUI-Passwort bereitstellen können, wenn kein Passwort konfiguriert ist.

Im Community-Thread sah der relevante Text im Containerprotokoll folgendermaßen aus:

Der WebUI-Administratorbenutzername lautet: admin
Das WebUI-Administratorkennwort wurde nicht festgelegt.
Für diese Sitzung wurde ein temporäres Passwort bereitgestellt:

Das tatsächliche temporäre Passwort erscheint nach dieser Meldung in der Containerausgabe.

So erhalten Sie das temporäre qBittorrent-Passwort in ZimaOS

Eine Antwort aus der Community schlug vor, das webbasierte ZimaOS-Terminal zu öffnen und Folgendes auszuführen:

docker logs qbittorrent

Der genaue Containername kann abweichen. Wenn dieser Befehl meldet, dass der Container nicht existiert, ermitteln Sie zunächst den richtigen Namen:

docker ps --format '{{.Names}}' | grep -i qbit

Lesen Sie anschließend die Protokolle des entsprechenden Containers.

Melden Sie sich anschließend an und legen Sie in den WebUI-Optionen von qBittorrent sofort ein eigenes starkes WebUI-Passwort fest. Ein sitzungsbezogen generiertes temporäres Passwort ist nicht als dauerhafte Zugangsdaten gedacht.

Informationen zum aktuellen Wiederherstellungsverhalten der Upstream-Version finden Sie in der Dokumentation zur Wiederherstellung des qBittorrent-WebUI-Passworts.

Was tun, wenn „docker logs“ die Berechtigung verweigert?

Die letzte Antwort im Community-Thread lautete:

WARNUNG: Fehler beim Laden der Konfigurationsdatei: open /DATA/.docker/config.json: Berechtigung verweigert

Berechtigungsverweigerung beim Versuch, eine Verbindung zum Docker-Daemon-Socket unter unix:///var/run/docker.sock herzustellen

Das ist ein Docker-Berechtigungsproblem des Hosts und kein qBittorrent-Passwortfehler. Der Shell-Benutzer, der docker logs hat keine Berechtigung, mit dem Docker-Daemon zu kommunizieren.

Verwenden Sie den autorisierten administrativen ZimaOS-Terminal-Workflow für Docker-Diagnosen. Versuchen Sie nicht, /var/run/docker.sock für alle beschreibbar und erweitern Sie die Host-Berechtigungen nicht pauschal, nur um ein einzelnes Protokoll zu lesen.

Nicht davon ausgehen, dass adminadmin das aktuelle Standardpasswort ist

In älteren qBittorrent-Dokumentationen und -Versionen wurde häufig Folgendes verwendet:

Benutzername: admin
Passwort: adminadmin

Die aktuelle qBittorrent-Dokumentation zur Wiederherstellung unterscheidet zwischen Versionen vor und nach 4.6.1. In neueren Versionen führt das Löschen oder Fehlen des konfigurierten Passworts dazu, dass qBittorrent ein temporäres Passwort ausgibt, anstatt einfach ein vorhersehbares dauerhaftes Standardpasswort wiederherzustellen.

Wenn ZimaOS Sie daher auffordert, „aus dem Protokoll abzurufen“, verwenden Sie die Containerprotokolle, anstatt wiederholt zu versuchen, adminadmin.

Dauerhaften WebUI-Benutzernamen und dauerhaftes WebUI-Passwort festlegen

Sobald Sie sich anmelden können:

Öffnen Sie Tools > Optionen > WebUI.
Legen Sie ein starkes WebUI-Passwort fest.
Behalten Sie den Administrator-Benutzernamen bei oder ändern Sie ihn entsprechend den in Ihrer installierten Version verfügbaren Optionen.
Speichern Sie die Einstellungen.
Öffnen Sie eine neue Browsersitzung und bestätigen Sie, dass die neuen Zugangsdaten funktionieren.

Die Antwort aus der Community schlug außerdem vor, die Authentifizierung für Localhost-Clients zu umgehen. Aktivieren Sie die Umgehung der Authentifizierung nicht umfassender als erforderlich. Eine qBittorrent-WebUI kann Downloads hinzufügen und Anwendungseinstellungen ändern, daher sollte der Zugriff auf vertrauenswürdige Clients beschränkt bleiben.

Host-Header- oder CSRF-Schutz nicht als erste Maßnahme deaktivieren

qBittorrent enthält Host-Header- und CSRF-Schutz aus gutem Grund. Eine globale Deaktivierung kann die Angriffsfläche der WebUI vergrößern und einen falsch konfigurierten Reverse-Proxy oder Dashboard-Link verschleiern.

Wenn der direkte Zugriff über:

http://ZIMAOS_LAN_IP:PORT

funktioniert, aber eine benutzerdefinierte Domain oder ein Reverse-Proxy-Link „Unauthorized“ zurückgibt, konfigurieren Sie den Proxy so, dass er die korrekten Host-/Origin-Informationen übermittelt, und befolgen Sie die aktuellen Hinweise von qBittorrent zur Verwendung eines Reverse-Proxys. Vermeiden Sie großzügige Wildcards, nur um den Fehler zu beseitigen.

qBittorrent-Protokolle auf die konkrete WebUI-Ablehnung prüfen

Der aktuelle qBittorrent-WebUI-Code protokolliert Bedingungen wie ungültige Host-Header oder Abweichungen beim Origin. Wenn der Browser vor der Anmeldeseite „Unauthorized“ anzeigt, lesen Sie die Containerprotokolle, während Sie die Anfrage reproduzieren.

Möglicherweise werden Meldungen angezeigt, die auf Folgendes hinweisen:

Validierung des Host-Headers;
Abweichung zwischen Origin und Referer;
Fehlgeschlagene Authentifizierung;
Generierung eines temporären Passworts;
oder als ein nicht zusammenhängendes Problem beim Start der Anwendung.

Das ist zuverlässiger, als jede Seite im 401-Stil als Cookie-Problem zu behandeln.

Checkliste zur Fehlerbehebung bei „Unauthorized“ in qBittorrent

Bestätigen Sie, dass der qBittorrent-Container ausgeführt wird.
Überprüfen Sie den aktuellen Host-Port der qBittorrent-WebUI in ZimaOS.
Öffnen Sie die vollständige URL http://ZIMAOS_LAN_IP:PORT.
Versuchen Sie ein privates Browserfenster nur zur Diagnose von Sitzung und Cache.
Wenn die Anmeldeseite angezeigt wird, beenden Sie die Untersuchung der Host-Header und rufen Sie die tatsächlichen qBittorrent-Zugangsdaten ab.
Bei qBittorrent 4.6.1 und höher sollten Sie die Container-Logs auf das vorübergehende Passwort prüfen, wenn kein dauerhaftes Passwort festgelegt ist.
Legen Sie nach der Anmeldung ein neues, starkes WebUI-Passwort fest.
Wenn der direkte Zugriff über die IP-Adresse funktioniert, aber ein Proxy oder eine Domain fehlschlägt, überprüfen Sie die Host-/Origin-Konfiguration des Reverse-Proxys.
Deaktivieren Sie die qBittorrent-WebUI-Sicherheitsprüfungen nicht grundsätzlich als erste Übergangslösung.
Wenn Docker-Logs nicht gelesen werden können, beheben Sie das Problem mit dem administrativen Zugriff auf den Host separat.

FAQ zur Fehlerbehebung bei „Unauthorized“ in qBittorrent unter ZimaOS

Warum wurde die „Unauthorized“-Seite durch das Hinzufügen von http:// behoben?

Dadurch wurde der Browser gezwungen, den erwarteten HTTP-Ursprung zu verwenden, anstatt die Adresse anders zu interpretieren oder hochzustufen. qBittorrent führt eine Validierung von WebUI-Host und Cross-Site-Anfragen durch, daher können Protokoll und Anfrage-Header beeinflussen, ob die Anfrage akzeptiert wird.

Wie lautet das qBittorrent-WebUI-Passwort unter ZimaOS?

Das hängt von der installierten qBittorrent-Version und der vorhandenen Konfiguration ab. Bei modernen Versionen kann qBittorrent ohne konfiguriertes Passwort ein vorübergehendes Passwort generieren und es in den Container-Logs ausgeben. ZimaOS kann Sie ausdrücklich dazu auffordern, das Passwort aus diesen Logs abzurufen.

Ist admin/adminadmin noch das Standardpasswort?

Verlassen Sie sich bei aktuellen qBittorrent-Versionen nicht darauf. Das qBittorrent-Projekt hat in Version 4.6.1 die Handhabung des Passworts beim ersten Start geändert, sodass ein nicht gesetztes WebUI-Passwort stattdessen zu einem vorübergehend generierten Passwort führen kann.

Nicht unbedingt. Ein privates Fenster hat bei einem Community-Nutzer vorübergehend geholfen, aber spätere Tests konnten das Problem nicht zuverlässig beseitigen. Auch die Validierung von URL und Protokoll sowie die WebUI-Sicherheit auf dem Server kommen als Ursachen infrage.

Warum wird bei „docker logs qbittorrent“ angezeigt, dass der Zugriff auf den Docker-Socket verweigert wurde?

Das aktuelle Terminalkonto ist nicht berechtigt, auf den Docker-Daemon zuzugreifen. Das ist unabhängig von der qBittorrent-Authentifizierung. Verwenden Sie eine autorisierte administrative Shell, anstatt die Berechtigungen des Docker-Sockets zu lockern.