Community Solution

Fix qBittorrent WebUI Unauthorized Errors on 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.

A plain white Unauthorized page in qBittorrent is not always the same problem as entering the wrong username or password. The IceWhale Community thread contains both situations: some users could not reach the qBittorrent WebUI correctly until they opened the ZimaOS server with an explicit http:// URL, while later users reached the login screen but did not know where the generated qBittorrent password was stored.

The safest troubleshooting approach is therefore to separate WebUI request validation from WebUI authentication. First make sure the browser is reaching qBittorrent through the correct URL and protocol. Only after the login screen loads should you troubleshoot the admin username and temporary password.

First Try the Explicit http:// URL

A February 2025 community reply reported that simply adding http:// in front of the server IP solved the Unauthorized page:

http://ZIMAOS_LAN_IP:QBITTORRENT_PORT

Another user later confirmed that this got them to the qBittorrent WebUI login page.

Use the actual host-side qBittorrent WebUI port shown in your ZimaOS app settings. If the app exposes 8080 directly, the URL may look like:

http://192.168.1.50:8080

Do not assume every ZimaOS qBittorrent package uses the same host port.

Why Can the URL Itself Cause “Unauthorized”?

qBittorrent WebUI includes security checks beyond the login form. Current qBittorrent source code can return an Unauthorized response when its Host-header validation or cross-site request protection rejects a request.

That means these can behave differently:

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

if the browser, dashboard, reverse proxy, origin, or protocol causes different request headers. The community result does not prove that every Unauthorized page is caused by missing http://, but it makes the explicit LAN URL a good first diagnostic.

A Private Browser Window Is a Diagnostic, Not a Complete Fix

The first community suggestion was to try a private browser window. One user reported that it worked once, which initially made the issue look like a cookie problem. Later tests showed that private browsing did not solve the problem consistently.

Use an incognito/private window to rule out stale session data, but do not stop troubleshooting there. If the error returns, test the explicit HTTP URL and review qBittorrent logs.

If You Reach the Login Screen, Solve the Password Separately

A later user could reach the qBittorrent login page after adding http:// but then tried combinations of the ZimaOS password, an empty password, and admin. Those credentials are not necessarily related.

Modern qBittorrent versions changed their first-run WebUI authentication behavior. The current official qBittorrent password-recovery documentation states that qBittorrent 4.6.1 and later can provide a temporary WebUI password when no password is configured.

In the community thread, the relevant container log text looked like:

The WebUI administrator username is: admin
The WebUI administrator password was not set.
A temporary password is provided for this session:

The actual temporary password appears in the container output after that message.

How to Get the Temporary qBittorrent Password in ZimaOS

A community reply suggested opening the ZimaOS Web-based Terminal and running:

docker logs qbittorrent

The exact container name can differ, so if that command says the container does not exist, identify it first:

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

Then read the appropriate container logs.

After logging in, immediately set your own strong WebUI password under qBittorrent's WebUI options. A session-generated temporary password is not intended to become your permanent credential.

For the current upstream recovery behavior, see the qBittorrent WebUI password recovery documentation.

What If docker logs Returns Permission Denied?

The last reply in the community thread reported:

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

That is a host Docker-permission problem, not a qBittorrent password error. The shell user running docker logs does not have permission to communicate with the Docker daemon.

Use the authorized ZimaOS administrative terminal workflow for Docker diagnostics. Do not make /var/run/docker.sock world-writable and do not loosen host permissions broadly just to read one log.

Do Not Assume adminadmin Is the Current Default Password

Older qBittorrent documentation and releases commonly used:

Username: admin
Password: adminadmin

Current qBittorrent recovery documentation distinguishes versions before and after 4.6.1. On newer releases, deleting or missing the configured password causes qBittorrent to print a temporary password rather than simply restoring a predictable permanent default.

Therefore, when ZimaOS tells you to “get from log,” use the container logs instead of repeatedly trying adminadmin.

Set a Permanent WebUI Username and Password

Once you can log in:

  1. Open Tools > Options > WebUI.
  2. Set a strong WebUI password.
  3. Keep the admin username or change it according to the options available in your installed release.
  4. Save the settings.
  5. Open a new browser session and confirm the new credentials work.

The community reply also suggested bypassing authentication for localhost clients. Do not enable authentication bypass more broadly than required. A qBittorrent WebUI can add downloads and change application settings, so access should remain limited to trusted clients.

Do Not Disable Host Header or CSRF Protection as the First Fix

qBittorrent includes Host-header and CSRF protections for a reason. Disabling them globally can expand the WebUI's exposure and can hide a misconfigured reverse proxy or dashboard link.

If direct access through:

http://ZIMAOS_LAN_IP:PORT

works but a custom domain or reverse-proxy link returns Unauthorized, configure the proxy to send the correct host/origin information and follow qBittorrent's current reverse-proxy guidance. Avoid setting permissive wildcards solely to remove the error.

Check qBittorrent Logs for the Specific WebUI Rejection

Current qBittorrent WebUI code logs conditions such as invalid Host headers or origin mismatches. If the browser shows Unauthorized before the login page, read the container logs while reproducing the request.

You may see messages that point to:

  • Host-header validation;
  • Origin or Referer mismatch;
  • failed authentication;
  • temporary-password generation;
  • or an unrelated application startup problem.

This is more reliable than treating every 401-style page as a cookie bug.

qBittorrent Unauthorized Troubleshooting Checklist

  1. Confirm the qBittorrent container is running.
  2. Check the current ZimaOS host port for the qBittorrent WebUI.
  3. Open the explicit URL http://ZIMAOS_LAN_IP:PORT.
  4. Try a private browser window only as a session/cache diagnostic.
  5. If the login page appears, stop troubleshooting Host headers and retrieve the actual qBittorrent credentials.
  6. For qBittorrent 4.6.1+, check container logs for the temporary password when no permanent password is set.
  7. Set a new strong WebUI password after logging in.
  8. If direct IP access works but a proxy/domain fails, troubleshoot the reverse-proxy Host/Origin configuration.
  9. Do not disable qBittorrent WebUI security checks globally as the first workaround.
  10. If Docker logs cannot be read, fix the host administrative-access issue separately.

qBittorrent Unauthorized on ZimaOS FAQ

Why did adding http:// fix the Unauthorized page?

It forced the browser to use the expected HTTP origin instead of interpreting or upgrading the address differently. qBittorrent performs WebUI Host and cross-site validation, so protocol and request headers can affect whether the request is accepted.

What is the qBittorrent WebUI password on ZimaOS?

It depends on the installed qBittorrent version and existing configuration. On modern versions with no configured password, qBittorrent can generate a temporary password and print it in the container logs. ZimaOS may explicitly instruct you to get the password from those logs.

Is admin/adminadmin still the default?

Do not rely on it for current qBittorrent releases. The qBittorrent project changed first-run password handling in version 4.6.1 so an unset WebUI password can result in a temporary generated password instead.

Not necessarily. A private window helped temporarily for one community user, but later testing did not make the problem consistently disappear. URL/protocol validation and server-side WebUI security are also possible causes.

Why does docker logs qbittorrent say Docker socket permission denied?

The current terminal account is not authorized to access the Docker daemon. That is separate from qBittorrent authentication. Use an authorized administrative shell rather than weakening Docker socket permissions.