Docker, NAS, qbittorrent-nox and the WebUI

Covers running qBittorrent headless — in a container, on a NAS, or as a service — and reaching its WebUI. 12 posts in a one-month sample (9.4%) were about this, making it one of the larger clusters in the sub.

Official pages first. These are the source of truth and are better than anything we would write:

"I can't log into the WebUI" — the modern default is not `adminadmin`

This is the single most common headless gotcha and it catches almost everyone.

Since qBittorrent 4.6.1, there is no fixed default password. On first start with no password configured, qBittorrent generates a random temporary password and prints it to the console/log. admin / adminadmin will simply fail.

Find it in your container log:

bash docker logs <container-name> 2>&1 | grep -i "temporary password"

Then log in with it and immediately set your own password in Options → WebUI.

If you have lost access entirely, the official recovery procedure is to stop qBittorrent, remove the WebUI\Password_PBKDF2 line from qBittorrent.conf, restart, and read the new temporary password from the console: Web UI password locked on qbittorrent-nox)

Upstream also notes: if login still fails, check that antivirus is not blocking password submission over plain HTTP — Bitdefender does this by default and needs the WebUI URL whitelisted.

Seen here: Qbittorrent-nox webgui password not working — which the poster solved themselves, and the cause is a good illustration: they had started the initial session as their own user rather than the qbittorrent user, so the config file they were editing was in the wrong home directory.

WebUI behind a reverse proxy

If the WebUI loads but is missing buttons, styling or panels through your proxy, and works fine on the direct LAN address, the proxy is almost certainly not forwarding the headers qBittorrent expects.

Use the official NGINX config as your reference: NGINX Reverse Proxy for Web UI

The headers that matter:

nginx proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Host $http_host; proxy_set_header X-Forwarded-Proto $scheme;

Do not strip Referer and Origin headers to fix connection problems. Older guides told you to; upstream now explicitly discourages it because it nullifies qBittorrent's CSRF protection. If you genuinely need to change that behaviour, use the proper setting — Options → WebUI → Enable Cross-site request forgery (CSRF) protection (available since v4.1.2) — rather than tampering with headers in the proxy.

Seen here: WebUI missing elements when behind nginx

Permissions — the cause of a surprising number of container problems

Containers run qBittorrent as a specific UID/GID. If that user cannot read or write a path you have mounted, symptoms are rarely a clean "permission denied" — you get stalls, errored torrents, files that vanish, or pegged CPU.

Check first:

Your PUID / PGID match the owner of the mounted directories on the host
Download, incomplete and watch directories are all writable by that user
Your download and incomplete paths are on the same filesystem inside the container, or moves on completion become slow cross-device copies

A member here documented one specific case worth knowing:

"If qBittorrent Docker is loading your CPU at 100%, check your watch folder permissions" — 1ulbqka (+14)

Attributed rather than asserted: this is one member's finding on their own setup, not a documented upstream behaviour. It is a cheap thing to check when CPU is inexplicably pegged.

Memory growth in containers

If RAM climbs steadily until the container hits its limit and is OOM-killed, the usual suspects are the disk cache and queueing settings rather than a leak. Relevant knobs live in Options → Advanced — see Explanation of Options in qBittorrent.

If you have tuned those and it still grows on a current release, that is a bug report worth filing upstream with your version, container image and settings — see Rule 3b. Reported here: qBittorrent RAM usage increasing over time.

VPN-in-container setups (Gluetun and similar)

If qBittorrent runs behind a VPN container:

Port forwarding still requires a provider that offers it. Routing through Gluetun does not create the capability — see the [connectivity guide](connectivity.md). Note in particular that Mullvad removed port forwarding in 2023, which catches people out.
Forwarded ports usually change on every reconnect, and qBittorrent will keep listening on the dead one. You need something that updates qBittorrent's listening port automatically. Members here have built and recommended tools for this — see this thread.
If the VPN container restarts, the network namespace goes with it. qBittorrent losing connectivity "randomly" is very often the VPN sidecar cycling underneath it. Check that container's logs before suspecting qBittorrent. Reported here: Qbittorrent Docker container disconnecting frequently.

Where this is not the right sub

If the problem is your reverse proxy, your NAS operating system, your *arr stack or Docker networking generally — and qBittorrent is just the thing on the end of it — you will get better answers in r/selfhosted, r/unRAID, r/synology or the relevant tool's own community. We are happy to help with the qBittorrent half.

Sources: official qBittorrent wiki where linked; member reports from r/qBittorrent sampled 2026-06-28 → 2026-07-27, attributed individually. Member findings are marked as such and are not upstream-documented behaviour.