"Failed to authenticate with qBittorrent" — fixing the password drift

Your downloads were working fine. Then you restarted the stack and Sonarr, Radarr, or Lidarr lit up with "Failed to authenticate with qBittorrent." Or you tried to set a new password and the reset command silently did nothing. The short version: qBittorrent's WebUI password and the copy your *arr apps remember have drifted apart, and a couple of older code paths made that drift sticky.

Rather not hand-edit a config file? SparkBox now runs a self-heal pass on every start that re-syncs a failing qBittorrent password automatically — and leaves working clients alone. See the walkthrough →

First, the vocabulary

A few terms you'll see throughout, defined once:

• WebUI — qBittorrent's web interface, the browser page you log into (usually on port 8080). The username and password it asks for are the "WebUI credentials."
• *arr apps — Sonarr (TV), Radarr (movies), and Lidarr (music). Each one stores qBittorrent's address, username, and password so it can hand off downloads. That stored copy is a "download client."
• qBittorrent.conf — qBittorrent's config file. The WebUI username and a hashed (scrambled, one-way) form of the password live here.
• Idempotency skip — when a setup script sees a value already exists and chooses to do nothing rather than overwrite it. Helpful most of the time; the cause of half this page's pain when the existing value is wrong.

Cause 1 — The *arr apps lose authentication after a restart

This is the headline symptom. After a stack restart, one or more *arr apps report they can't authenticate. The qBittorrent WebUI still works in your browser, which makes it confusing — the password qBittorrent is using and the password the *arr app saved no longer match.

Two things were making this stick:

1. The wiring step that registers qBittorrent inside each *arr app used to skip if a client already existed. So once the stored password went stale, re-running the bootstrap never corrected it — and Lidarr was never wired up at all.
2. There was no routine that checked whether the connection actually worked after a restart.

What changed

The registration step now updates the existing qBittorrent client in place (it edits the saved record instead of skipping it), so a re-run re-syncs the password. On top of that, a self-heal pass runs on every start. Crucially, it gates on each *arr's own download-client test: it re-applies the saved qBittorrent password only to a client that is genuinely failing authentication, and leaves a working or hand-fixed client untouched. That gate is what stops it from clobbering a password you set deliberately.

Fix it by hand

1. Confirm qBittorrent's real WebUI password by logging into the WebUI in your browser.
2. In each *arr app, open Settings → Download Clients and click your qBittorrent entry.
3. Re-enter the username (admin unless you deliberately changed it) and the current password, then click Test.
4. When the test passes, click Save. Repeat for every *arr app that was failing.

Cause 2 — reset-password silently did nothing

If you ran a password reset and qBittorrent kept asking for the old one, you hit the worst version of the idempotency skip. The injector that seeds the admin password used a "skip if a password already exists" rule, so on a reset there was already a password — and it bailed without writing yours.

What changed

In reset mode, the seed script now writes the admin username and the new password hash directly into qBittorrent.conf while the container is stopped. It drops any stale username and password lines first, then starts qBittorrent fresh so it reads the new value instead of relying on the skip-if-exists injector. The heal mode (the gentle auto-heal on start, described above) is deliberately left unchanged so it can't fight your reset.

Fix it

sudo sparkbox reset-password qbit

This is the reliable interim fix for the whole class of "password won't take" problems. After it runs, log into the WebUI with username admin and the password it printed, then re-run the steps in Cause 1 so each *arr app picks up the new value.

Cause 3 — You changed the WebUI username and locked yourself out

People reach for qBittorrent's own settings (Tools → Options → Web UI) and change the username, not just the password. That can lock you out of the WebUI entirely. The reset above will get you back in — but be aware it forces the username back to admin. There is no way around that with the current reset; plan for it.

Cause 4 — Fresh install: the admin password was never seeded

On some brand-new installs the admin password auto-seed silently did nothing, so qBittorrent came up with its own generated password rather than the one you expected. The root cause was a path mismatch: the LinuxServer.io base image's newer (v3) init system scans a different directory for startup scripts than the legacy one, so the seed script simply wasn't found and run.

What changed

The qBittorrent service now binds the same host init directory to both the legacy location and the v3 location, so the seed script is found regardless of which path the base image scans. The install step also tightens ownership of just that init subdirectory so the script is allowed to execute.

If you're on an older install

You don't need to chase the scan path by hand. Run the reset:

sudo sparkbox reset-password qbit

Because the reset writes straight into the config file with the container stopped, it doesn't depend on the init-scan path at all. That's why it works even when the on-install seed didn't.

Cause 5 — Protection settings missing after an upgrade

On the upgrade-from-old-SparkBox path, the init script used to exit early when it found a quirky existing password hash, and in doing so it skipped writing qBittorrent's two protection tweaks — HostHeaderValidation and CSRFProtection (settings that block certain cross-site and header-spoofing requests to the WebUI). The symptom is subtle: the password might be fine, but the WebUI behaves oddly behind a reverse proxy or refuses some requests.

What changed

That early exit was replaced with a fall-through: the password-injection block is skipped when the hash is already valid, but the protection-setting steps still run. They're written idempotently — they check for the lines before adding them, so re-runs don't duplicate anything. If you upgraded and saw WebUI weirdness, a normal start now repairs the missing settings.

A related fix you may have noticed: Duplicati

While auditing password state files, the team found a separate gap in Duplicati (the backup tool): its admin password was generated at install but never written to a readable state file, so the dashboard's Backups tile had nothing to show under its credentials icon. That's fixed as of v1.6.108 — the password is now staged to a state file and the dashboard surfaces it. It's unrelated to the qBittorrent logic, but if your Backups tile credentials were blank, that's the same wave of fixes.

Frequently asked

Why does Sonarr say it can't authenticate with qBittorrent after a restart?

On restart, qBittorrent can come up with a different WebUI password than the one your *arr apps stored. When the saved password no longer matches, the download-client test fails. Re-applying the correct password to qBittorrent and to each *arr client clears it; the self-heal pass now does this automatically for clients that are actually failing.

Why did sparkbox reset-password qbit do nothing?

The old reset skipped writing a new password if one already existed. The current reset writes the admin username and the new password hash directly into qBittorrent.conf while the container is stopped, removing stale lines first, then starts it fresh so qBittorrent reads the new value.

I changed the qBittorrent WebUI username and now I'm locked out. What now?

Run sudo sparkbox reset-password qbit. It rewrites the credentials, but it forces the username back to admin. Log in as admin afterward, and update any *arr download client that was using a custom username back to admin too.

Will the auto-heal overwrite a password I fixed myself?

No. The self-heal pass tests each *arr download client first and only re-applies the saved qBittorrent password to a client that is failing authentication. Working and hand-fixed clients are left untouched.