qBittorrent: ongeautoriseerde toegang op ZimaOS — oplossing voor WebUI-inloggen

Een volledig witte pagina met Unauthorized in qBittorrent is niet altijd hetzelfde probleem als het invoeren van de verkeerde gebruikersnaam of het verkeerde wachtwoord. De IceWhale Community-thread bevat beide situaties: sommige gebruikers konden de qBittorrent-WebUI pas correct bereiken nadat ze de ZimaOS-server openden met een expliciete http://-URL, terwijl latere gebruikers het inlogscherm wel bereikten maar niet wisten waar het gegenereerde qBittorrent-wachtwoord was opgeslagen.

De veiligste aanpak voor het oplossen van dit probleem is daarom om WebUI-aanvraagvalidatie te onderscheiden van WebUI-authenticatie. Zorg er eerst voor dat de browser qBittorrent via de juiste URL en het juiste protocol bereikt. Pas nadat het inlogscherm is geladen, moet je de beheerdersgebruikersnaam en het tijdelijke wachtwoord onderzoeken.

Probeer eerst de expliciete http://-URL

In een communityreactie uit februari 2025 werd gemeld dat het simpelweg toevoegen van http:// vóór het IP-adres van de server op te nemen, werd de Unauthorized-pagina opgelost:

http://ZIMAOS_LAN_IP:QBITTORRENT_PORT

Een andere gebruiker bevestigde later dat dit hem naar de qBittorrent-WebUI-inlogpagina bracht.

Gebruik de daadwerkelijke qBittorrent-WebUI-hostpoort die in de appinstellingen van ZimaOS wordt weergegeven. Als de app poort 8080 rechtstreeks beschikbaar stelt, kan de URL er als volgt uitzien:

http://192.168.1.50:8080

Ga er niet van uit dat elk qBittorrent-pakket voor ZimaOS dezelfde hostpoort gebruikt.

Waarom kan de URL zelf “Unauthorized” veroorzaken?

De qBittorrent-WebUI bevat naast het inlogformulier ook beveiligingscontroles. De huidige qBittorrent-broncode kan een Unauthorized-reactie retourneren wanneer de validatie van de Host-header of de bescherming tegen cross-site-aanvragen een aanvraag afwijst.

Dat betekent dat deze zich verschillend kunnen gedragen:

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

als de browser, het dashboard, de reverse proxy, de origin of het protocol verschillende aanvraagheaders veroorzaakt. Het resultaat uit de community bewijst niet dat elke pagina met de melding Unauthorized wordt veroorzaakt door een ontbrekende http://, maar hierdoor is de expliciete LAN-URL een goede eerste diagnostische stap.

Een privébrowservenster is een diagnosemiddel, geen volledige oplossing

De eerste suggestie uit de community was om een privébrowservenster te proberen. Eén gebruiker meldde dat dit één keer werkte, waardoor het probleem aanvankelijk op een cookieprobleem leek. Latere tests lieten zien dat privé browsen het probleem niet consequent oploste.

Gebruik een incognito-/privévenster om verouderde sessiegegevens uit te sluiten, maar stop daar niet met het oplossen van het probleem. Als de fout terugkomt, test dan de expliciete HTTP-URL en bekijk de qBittorrent-logboeken.

Een latere gebruiker kon de qBittorrent-inlogpagina bereiken nadat die http:// maar probeerde vervolgens combinaties van het ZimaOS-wachtwoord, een leeg wachtwoord en admin. Die inloggegevens houden niet noodzakelijk verband met elkaar.

Moderne versies van qBittorrent hebben het authenticatiegedrag bij de eerste start gewijzigd. In de huidige officiële documentatie van qBittorrent voor wachtwoordherstel staat dat qBittorrent 4.6.1 en hoger een tijdelijk WebUI-wachtwoord kan verstrekken wanneer er geen wachtwoord is geconfigureerd.

In de communitydiscussie zag de relevante containerlogtekst er als volgt uit:

De gebruikersnaam van de WebUI-beheerder is: admin
Het beheerderswachtwoord voor de WebUI is niet ingesteld.
Voor deze sessie is een tijdelijk wachtwoord verstrekt:

Het daadwerkelijke tijdelijke wachtwoord verschijnt na dat bericht in de containeruitvoer.

Zo verkrijg je het tijdelijke qBittorrent-wachtwoord in ZimaOS

Een communityreactie stelde voor om de webterminal van ZimaOS te openen en het volgende uit te voeren:

docker logs qbittorrent

De exacte containernaam kan verschillen. Als dat commando aangeeft dat de container niet bestaat, zoek je die eerst op:

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

Lees vervolgens de juiste containerlogboeken.

Stel na het inloggen onmiddellijk je eigen sterke WebUI-wachtwoord in via de WebUI-opties van qBittorrent. Een tijdelijk, door de sessie gegenereerd wachtwoord is niet bedoeld als permanente inloggegevens.

Bekijk voor het huidige herstelgedrag de documentatie over het herstellen van het qBittorrent WebUI-wachtwoord.

Wat als docker logs Toegang geweigerd retourneert?

De laatste reactie in de communitydiscussie meldde:

WARNING: Error loading config file: open /DATA/.docker/config.json: permission denied

permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock

Dat is een Docker-machtigingsprobleem op de host, geen qBittorrent-wachtwoordfout. De shellgebruiker die docker logs heeft geen toestemming om met de Docker-daemon te communiceren.

Gebruik de geautoriseerde ZimaOS-beheerdersworkflow in de terminal voor Docker-diagnostiek. Maak geen /var/run/docker.sock wereldschrijfbaar en versoepel de hostrechten niet in brede zin alleen om één logboek te kunnen lezen.

Ga er niet van uit dat adminadmin het huidige standaardwachtwoord is

In oudere documentatie en versies van qBittorrent werd vaak het volgende gebruikt:

Gebruikersnaam: admin
Wachtwoord: adminadmin

De huidige documentatie voor herstel van qBittorrent maakt onderscheid tussen versies vóór en vanaf 4.6.1. In nieuwere versies zorgt het verwijderen van of ontbreken van het geconfigureerde wachtwoord ervoor dat qBittorrent een tijdelijk wachtwoord afdrukt, in plaats van eenvoudigweg een voorspelbaar permanent standaardwachtwoord te herstellen.

Wanneer ZimaOS je daarom vraagt om dit “uit het logboek te halen”, gebruik je dus de containerlogboeken in plaats van het herhaaldelijk te proberen adminadmin.

Stel een permanente gebruikersnaam en wachtwoord voor de WebUI in

Zodra je kunt inloggen:

Open Tools > Options > WebUI.
Stel een sterk WebUI-wachtwoord in.
Houd de gebruikersnaam van de beheerder aan of wijzig deze volgens de beschikbare opties in de geïnstalleerde versie.
Sla de instellingen op.
Open een nieuwe browsersessie en bevestig dat de nieuwe inloggegevens werken.

In het communityantwoord werd ook voorgesteld om authenticatie voor localhost-clients te omzeilen. Schakel de authenticatieomzeiling niet breder in dan noodzakelijk. Een qBittorrent WebUI kan downloads toevoegen en applicatie-instellingen wijzigen, dus de toegang moet beperkt blijven tot vertrouwde clients.

Schakel Host-header- of CSRF-beveiliging niet uit als eerste oplossing

qBittorrent bevat Host-header- en CSRF-beveiliging met een reden. Als je deze globaal uitschakelt, kan de blootstelling van de WebUI toenemen en kan een verkeerd geconfigureerde reverse proxy of dashboardkoppeling onopgemerkt blijven.

Als directe toegang via:

http://ZIMAOS_LAN_IP:PORT

werkt, maar een aangepast domein of een reverse-proxykoppeling Unauthorized retourneert, configureer de proxy dan om de juiste host- en origininformatie te verzenden en volg de actuele richtlijnen van qBittorrent voor reverse proxies. Stel geen onbeperkte wildcards in uitsluitend om de fout te verwijderen.

Controleer de qBittorrent-logboeken op de specifieke afwijzing door de WebUI

De huidige qBittorrent WebUI-code logt omstandigheden zoals ongeldige Host-headers of verschillen in origin. Als de browser Unauthorized weergeeft voordat de aanmeldpagina verschijnt, bekijk dan de containerlogboeken terwijl je het verzoek opnieuw uitvoert.

Je kunt meldingen zien die wijzen op:

validatie van de Host-header;
verschil tussen Origin en Referer;
mislukte authenticatie;
genereren van een tijdelijk wachtwoord;
of een niet-gerelateerd probleem bij het opstarten van de applicatie.

Dit is betrouwbaarder dan elke pagina in de stijl van 401 als een cookieprobleem behandelen.

Checklist voor het oplossen van qBittorrent ‘Unauthorized’

Bevestig dat de qBittorrent-container actief is.
Controleer de huidige hostpoort van ZimaOS voor de qBittorrent WebUI.
Open de expliciete URL http://ZIMAOS_LAN_IP:PORT.
Probeer alleen een privébrowservenster als diagnostiek voor de sessie- of cache.
Als de inlogpagina verschijnt, stop dan met het onderzoeken van Host-headers en haal de daadwerkelijke qBittorrent-inloggegevens op.
Controleer voor qBittorrent 4.6.1+ de containerlogboeken op het tijdelijke wachtwoord wanneer er geen permanent wachtwoord is ingesteld.
Stel na het inloggen een nieuw sterk WebUI-wachtwoord in.
Als directe toegang via het IP-adres werkt maar een proxy of domein niet, controleer dan de Host-/Origin-configuratie van de reverse proxy.
Schakel de beveiligingscontroles van de qBittorrent WebUI niet globaal uit als eerste workaround.
Als Docker-logboeken niet kunnen worden gelezen, los dan het probleem met de beheerderstoegang tot de host afzonderlijk op.

qBittorrent ‘Unauthorized’ op ZimaOS: veelgestelde vragen

Waarom verdween de pagina ‘Unauthorized’ nadat ik http:// had toegevoegd?

De browser werd gedwongen de verwachte HTTP-origin te gebruiken in plaats van het adres anders te interpreteren of automatisch te upgraden. qBittorrent voert Host- en cross-site-validatie voor de WebUI uit, waardoor het protocol en de aanvraagheaders van invloed kunnen zijn op de vraag of de aanvraag wordt geaccepteerd.

Wat is het qBittorrent WebUI-wachtwoord op ZimaOS?

Dat hangt af van de geïnstalleerde qBittorrent-versie en de bestaande configuratie. In moderne versies kan qBittorrent, wanneer er geen wachtwoord is ingesteld, een tijdelijk wachtwoord genereren en dit in de containerlogboeken afdrukken. ZimaOS kan u expliciet vragen het wachtwoord uit die logboeken te halen.

Is admin/adminadmin nog steeds de standaard?

Vertrouw hier niet op bij recente qBittorrent-releases. Het qBittorrent-project heeft in versie 4.6.1 de afhandeling van het wachtwoord bij de eerste start gewijzigd, waardoor een niet-ingesteld WebUI-wachtwoord kan leiden tot een tijdelijk gegenereerd wachtwoord.

Niet per se. Een privévenster hielp tijdelijk bij één communitygebruiker, maar uit latere tests bleek niet dat het probleem daardoor consequent verdween. Validatie van de URL en het protocol, evenals WebUI-beveiliging aan de serverzijde, kunnen ook mogelijke oorzaken zijn.

Waarom zegt docker logs qbittorrent dat toegang tot de Docker-socket is geweigerd?

Het huidige terminalaccount is niet gemachtigd om toegang te krijgen tot de Docker-daemon. Dit staat los van qBittorrent-authenticatie. Gebruik een gemachtigde shell met beheerdersrechten in plaats van de rechten op de Docker-socket te verzwakken.