Solution communautaire

Corriger les erreurs d’accès non autorisé de l’interface Web de qBittorrent sur ZimaOS

A ZimaOS qBittorrent thread found that an Unauthorized page could sometimes be bypassed by opening the server with an explicit http:// URL, while later users also needed the temporary WebUI password printed in the container logs.

Une page blanche affichant Unauthorized dans qBittorrent n’est pas toujours le même problème que la saisie d’un nom d’utilisateur ou d’un mot de passe incorrect. Le fil de discussion de la communauté IceWhale décrit les deux situations : certains utilisateurs ne pouvaient pas accéder correctement à l’interface Web de qBittorrent avant d’ouvrir le serveur ZimaOS avec une URL explicite en http://, tandis que les utilisateurs suivants accédaient à l’écran de connexion, mais ne savaient pas où était stocké le mot de passe qBittorrent généré.

L’approche de dépannage la plus sûre consiste donc à distinguer la validation des requêtes de l’interface Web de l’authentification à l’interface Web. Commencez par vérifier que le navigateur accède à qBittorrent via l’URL et le protocole appropriés. Ce n’est qu’une fois l’écran de connexion chargé que vous devez dépanner le nom d’utilisateur administrateur et le mot de passe temporaire.

Essayez d’abord l’URL http:// explicite

Une réponse de la communauté publiée en février 2025 indiquait qu’il suffisait d’ajouter http:// placé devant l’adresse IP du serveur a résolu le problème de la page « Unauthorized » :

http://ZIMAOS_LAN_IP:QBITTORRENT_PORT

Un autre utilisateur a ensuite confirmé que cela l’avait conduit à la page de connexion de l’interface Web de qBittorrent.

Utilisez le port de l’interface Web de qBittorrent côté hôte affiché dans les paramètres de votre application ZimaOS. Si l’application expose directement le port 8080, l’URL peut ressembler à ceci :

http://192.168.1.50:8080

Ne supposez pas que tous les paquets qBittorrent de ZimaOS utilisent le même port hôte.

Pourquoi l’URL elle-même peut-elle provoquer une erreur « Unauthorized » ?

L’interface Web de qBittorrent applique des contrôles de sécurité qui vont au-delà du formulaire de connexion. Le code source actuel de qBittorrent peut renvoyer une réponse « Unauthorized » lorsque la validation de l’en-tête Host ou la protection contre les requêtes intersites rejette une requête.

Cela signifie que les éléments suivants peuvent se comporter différemment :

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

si le navigateur, le tableau de bord, le proxy inverse, l’origine ou le protocole entraîne l’envoi d’en-têtes de requête différents. Le résultat obtenu par la communauté ne prouve pas que chaque page « Unauthorized » est due à l’absence de http://, mais cela fait de l’URL LAN explicite un bon premier outil de diagnostic.

Une fenêtre de navigation privée est un outil de diagnostic, pas une solution complète

La première suggestion de la communauté consistait à essayer une fenêtre de navigation privée. Un utilisateur a indiqué que cela avait fonctionné une fois, ce qui a d’abord donné l’impression qu’il s’agissait d’un problème de cookies. Des tests ultérieurs ont montré que la navigation privée ne résolvait pas le problème de manière systématique.

Utilisez une fenêtre de navigation privée pour écarter les données de session obsolètes, mais ne vous arrêtez pas là dans le dépannage. Si l’erreur réapparaît, testez l’URL HTTP explicite et consultez les journaux de qBittorrent.

Si vous atteignez l’écran de connexion, résolvez séparément le problème de mot de passe

Un utilisateur ultérieur a pu accéder à la page de connexion de qBittorrent après avoir ajouté http:// mais a ensuite essayé différentes combinaisons avec le mot de passe ZimaOS, un mot de passe vide et admin. Ces identifiants ne sont pas nécessairement liés.

Les versions modernes de qBittorrent ont modifié le comportement d’authentification de l’interface Web lors de la première exécution. La documentation officielle actuelle de récupération du mot de passe de qBittorrent indique que qBittorrent 4.6.1 et les versions ultérieures peuvent fournir un mot de passe WebUI temporaire lorsqu’aucun mot de passe n’est configuré.

Dans le fil de discussion de la communauté, le texte pertinent des journaux du conteneur ressemblait à ceci :

Le nom d’utilisateur administrateur de l’interface Web est : admin
Le mot de passe administrateur de l’interface Web n’a pas été défini.
Un mot de passe temporaire est fourni pour cette session :

Le mot de passe temporaire réel apparaît dans la sortie du conteneur après ce message.

Comment obtenir le mot de passe temporaire de qBittorrent dans ZimaOS

Une réponse de la communauté suggérait d’ouvrir le terminal Web de ZimaOS et d’exécuter :

docker logs qbittorrent

Le nom exact du conteneur peut varier. Si cette commande indique que le conteneur n’existe pas, identifiez-le d’abord :

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

Lisez ensuite les journaux du conteneur approprié.

Après vous être connecté, définissez immédiatement votre propre mot de passe WebUI robuste dans les options WebUI de qBittorrent. Un mot de passe temporaire généré pour la session n’est pas destiné à devenir votre identifiant permanent.

Pour connaître le comportement actuel de récupération en amont, consultez la documentation de récupération du mot de passe de l’interface Web de qBittorrent.

Que faire si docker logs renvoie « Permission denied » ?

La dernière réponse dans le fil de discussion de la communauté indiquait :

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

Il s’agit d’un problème d’autorisation Docker sur l’hôte, et non d’une erreur de mot de passe qBittorrent. L’utilisateur du shell qui exécute docker logs n’a pas l’autorisation de communiquer avec le démon Docker.

Utilisez le terminal administratif ZimaOS autorisé pour diagnostiquer Docker. Ne faites pas /var/run/docker.sock accessible en écriture à tous ; n’élargissez pas les autorisations de l’hôte uniquement pour lire un seul journal.

Ne supposez pas que adminadmin est le mot de passe par défaut actuel

Les anciennes versions et la documentation de qBittorrent utilisaient généralement :

Nom d’utilisateur : admin
Mot de passe : adminadmin

La documentation actuelle de récupération de qBittorrent distingue les versions antérieures et postérieures à la 4.6.1. Dans les versions plus récentes, la suppression du mot de passe configuré ou son absence amène qBittorrent à afficher un mot de passe temporaire au lieu de simplement restaurer une valeur permanente prévisible.

Par conséquent, lorsque ZimaOS vous demande de « récupérer depuis le journal », utilisez les journaux du conteneur au lieu de réessayer sans cesse adminadmin.

Définir un nom d’utilisateur et un mot de passe permanents pour l’interface Web

Une fois connecté :

  1. Ouvrez Outils > Options > Interface Web.
  2. Définissez un mot de passe fort pour l’interface Web.
  3. Conservez le nom d’utilisateur administrateur ou modifiez-le selon les options disponibles dans la version installée.
  4. Enregistrez les paramètres.
  5. Ouvrez une nouvelle session de navigateur et confirmez que les nouveaux identifiants fonctionnent.

La réponse de la communauté suggérait également de contourner l’authentification pour les clients localhost. N’activez pas un contournement de l’authentification plus large que nécessaire. Une interface Web qBittorrent permet d’ajouter des téléchargements et de modifier les paramètres de l’application ; l’accès doit donc rester limité aux clients de confiance.

Ne désactivez pas la protection de l’en-tête Host ou contre les requêtes CSRF comme première solution

qBittorrent intègre des protections contre les en-têtes Host et les requêtes CSRF pour une bonne raison. Les désactiver globalement peut élargir l’exposition de l’interface Web et masquer un proxy inverse ou un lien de tableau de bord mal configuré.

Si l’accès direct via :

http://ZIMAOS_LAN_IP:PORT

fonctionne, mais qu’un domaine personnalisé ou un lien passant par un proxy inverse renvoie « Non autorisé », configurez le proxy pour envoyer les informations correctes concernant l’hôte et l’origine, puis suivez les recommandations actuelles de qBittorrent concernant les proxys inverses. Évitez de définir des caractères génériques permissifs uniquement pour supprimer l’erreur.

Vérifier les journaux de qBittorrent pour connaître le rejet spécifique de l’interface Web

Le code actuel de l’interface Web de qBittorrent journalise notamment les conditions telles que les en-têtes Host invalides ou les discordances d’origine. Si le navigateur affiche « Non autorisé » avant la page de connexion, consultez les journaux du conteneur pendant la reproduction de la requête.

Vous pouvez voir des messages faisant référence aux éléments suivants :

  • validation de l’en-tête Host ;
  • discordance de l’origine ou du référent ;
  • échec de l’authentification ;
  • génération d’un mot de passe temporaire ;
  • ou comme un problème indépendant survenant au démarrage de l’application.

C’est plus fiable que de considérer chaque page de type 401 comme un problème de cookies.

Liste de vérification pour résoudre l’erreur « Unauthorized » de qBittorrent

  1. Confirmez que le conteneur qBittorrent est en cours d’exécution.
  2. Vérifiez le port hôte actuel de ZimaOS pour l’interface Web qBittorrent.
  3. Ouvrez l’URL explicite http://ZIMAOS_LAN_IP:PORT.
  4. Essayez une fenêtre de navigation privée uniquement pour diagnostiquer la session ou le cache.
  5. Si la page de connexion s’affiche, cessez de rechercher un problème lié aux en-têtes Host et récupérez les identifiants qBittorrent réels.
  6. Pour qBittorrent 4.6.1 et versions ultérieures, consultez les journaux du conteneur pour trouver le mot de passe temporaire lorsqu’aucun mot de passe permanent n’est défini.
  7. Définissez un nouveau mot de passe fort pour l’interface Web après la connexion.
  8. Si l’accès direct par adresse IP fonctionne mais qu’un proxy ou un domaine échoue, vérifiez la configuration de l’hôte et de l’origine dans le proxy inverse.
  9. Ne désactivez pas globalement les contrôles de sécurité de l’interface Web qBittorrent comme première solution de contournement.
  10. Si les journaux Docker ne peuvent pas être lus, corrigez séparément le problème d’accès administratif à l’hôte.

FAQ sur l’erreur « Unauthorized » de qBittorrent sur ZimaOS

Pourquoi l’ajout de http:// a-t-il résolu la page « Unauthorized » ?

Le navigateur a été contraint d’utiliser l’origine HTTP attendue au lieu d’interpréter ou de mettre à niveau l’adresse différemment. qBittorrent effectue une validation de l’hôte de l’interface Web et des requêtes intersites ; le protocole et les en-têtes de requête peuvent donc déterminer si la requête est acceptée.

Quel est le mot de passe de l’interface Web qBittorrent sur ZimaOS ?

Cela dépend de la version de qBittorrent installée et de la configuration existante. Dans les versions modernes sans mot de passe configuré, qBittorrent peut générer un mot de passe temporaire et l’afficher dans les journaux du conteneur. ZimaOS peut vous indiquer de récupérer le mot de passe dans ces journaux.

admin/adminadmin est-il toujours le mot de passe par défaut ?

Ne vous y fiez pas pour les versions actuelles de qBittorrent. Le projet qBittorrent a modifié la gestion du mot de passe lors du premier démarrage dans la version 4.6.1 : lorsqu’aucun mot de passe d’interface Web n’est défini, un mot de passe temporaire généré peut être utilisé à la place.

Pas nécessairement. Une fenêtre privée a temporairement aidé un utilisateur de la communauté, mais des tests ultérieurs n’ont pas confirmé que le problème disparaissait de manière constante. La validation de l’URL ou du protocole et la sécurité côté serveur de l’interface Web sont également des causes possibles.

Pourquoi la commande docker logs qbittorrent indique-t-elle que l’accès au socket Docker est refusé ?

Le compte du terminal actuel n’est pas autorisé à accéder au daemon Docker. Cela est distinct de l’authentification qBittorrent. Utilisez un shell administratif autorisé plutôt que d’affaiblir les permissions du socket Docker.