Made some progress since my last hiccup earlier but seem to be at another stoppage and not really sure where to head from here. I am able to access all of my apps now, and went through the configuration guide for Radarr and qBittorrent, but it will not let me add qBit as a Download Client. When using localhost, it throws an "Authentication Failure" error for the admin user. As I am using WSL2, I thought it might be since I wasn't using MYSERVERIP as the host, and so I tried using that but it then throws an "Unable to connect to qBittorrent" error. I attempted to change the port to 8089 as the Web UI uses that port, but that seems to not make a difference. Any help would be appreciated again as I hopefully won't run into any more hurdles with the setup process. Thank you again for all that you do!
10 replies
hailreaper wrote:
Not sure if this was happening before and causing this or if it happened after I tried to shut it down and bring it back up, but qBit is stuck in a loop of crashing and won't fully come up anymore. 2026-05-24T20:32:47.487076762Z k2026-05-24T20:32:47.487078062Z ██╗ ███████╗██╗ ██████╗ p2026-05-24T20:32:47.487079133Z ██║ ██╔════╝██║██╔═══██╗ j2026-05-24T20:32:47.487080081Z ██║ ███████╗██║██║ ██║ j2026-05-24T20:32:47.487080946Z ██║ ╚════██║██║██║ ██║ z2026-05-24T20:32:47.487081792Z ███████╗███████║██║╚██████╔╝ u2026-05-24T20:32:47.487082668Z ╚══════╝╚══════╝╚═╝ ╚═════╝ 2026-05-24T20:32:47.487083517Z C2026-05-24T20:32:47.487084276Z Brought to you by linuxserver.io �2026-05-24T20:32:47.487085138Z ─────────────────────────────────────── 2026-05-24T20:32:47.487183728Z ?2026-05-24T20:32:47.487192521Z To support LSIO projects visit: B2026-05-24T20:32:47.487193850Z https://www.linuxserver.io/donate/ 2026-05-24T20:32:47.487194927Z �2026-05-24T20:32:47.487196228Z ─────────────────────────────────────── '2026-05-24T20:32:47.487197503Z GID/UID �2026-05-24T20:32:47.487198354Z ─────────────────────────────────────── 2026-05-24T20:32:47.489057464Z 12026-05-24T20:32:47.489060381Z User UID: 1000 12026-05-24T20:32:47.489061105Z User GID: 1000 �2026-05-24T20:32:47.489061684Z ─────────────────────────────────────── K2026-05-24T20:32:47.489815284Z Linuxserver.io version: 5.2.0v2.0.12-ls458 E2026-05-24T20:32:47.489929249Z Build-date: 2026-05-17T08:57:46+00:00 �2026-05-24T20:32:47.489934231Z ─────────────────────────────────────── $2026-05-24T20:32:47.489935491Z P2026-05-24T20:32:47.518810544Z [custom-init] No custom files found, skipping... S2026-05-24T20:35:09.003449381Z [custom-init] No custom services found, skipping... 42026-05-24T20:35:09.017410468Z [migrations] started @2026-05-24T20:35:09.017424949Z [migrations] no migrations found 32026-05-24T20:35:09.031188651Z usermod: no changes �2026-05-24T20:35:09.036378310Z ───────────────────────────────────────
tomspark wrote:
You're close — and you didn't break anything. Manually stopping containers just got qBit out of sync with the VPN piece it rides on (that's the crash loop). Easiest fix is to bring the whole stack back up cleanly in one go: sudo sparkbox up Give it a minute and qBit should settle to healthy. Then for adding it in Radarr — here's the bit that trips everyone up: inside SparkBox, Radarr and qBittorrent share the same network, so the Host is just localhost and the Port is 8080 (qBit's internal port — NOT your server IP, and NOT 8089). Use the qBittorrent username/password from your dashboard at Settings → Monitoring & Tools → Service Passwords. That combo connects every time.
hailreaper wrote:
After using sudo sparkbox up, it still seems to be stuck in the loop after a few minutes.
tomspark wrote:
Thanks — that screenshot tells me qBit keeps dying right after it starts. Two quick things to paste so I can pinpoint why: docker ps -a | grep -E 'gluetun|qbittorrent' That shows whether the VPN container (gluetun) is healthy or also struggling — qBit rides on it, so if that's unhealthy, qBit can't stay up. Then grab qBit's actual error: docker logs sb-qbittorrent --tail 40 Paste both and I'll give you the exact fix. My hunch is either the VPN container needs a kick (common on WSL2 after a restart) or qBit's config got left half-written when it was force-stopped — the logs will say which.
hailreaper wrote:
root@Rivendell:~ docker ps -a | grep -E 'gluetun|qbittorrent' bdec70da4091 lscr.io/linuxserver/qbittorrent:5.2.0 "/init" About an hour ago Up 2 minutes (health: starting) sb-qbittorrent dbb7dd47646f qmcgaw/gluetun:v3.41.1 "/gluetun-entrypoint" About an hour ago Up About an hour (healthy) 0.0.0.0:7878-7878/tcp, [::]:7878-7878/tcp, 0.0.0.0:8191-8191/tcp, [::]:8191-8191/tcp, 0.0.0.0:8686-8686/tcp, [::]:8686-8686/tcp, 0.0.0.0:8989-8989/tcp, [::]:8989-8989/tcp, 0.0.0.0:8089-8080/tcp, [::]:8089-8080/tcp, 0.0.0.0:8186-8081/tcp, [::]:8186-8081/tcp, 0.0.0.0:8181-9696/tcp, [::]:8181-9696/tcp sb-gluetun root@Rivendell:~ docker ps -a | grep -E 'gluetun|qbittorrent' bdec70da4091 lscr.io/linuxserver/qbittorrent:5.2.0 "/init" About an hour ago Up 32 seconds (health: starting) sb-qbittorrent dbb7dd47646f qmcgaw/gluetun:v3.41.1 "/gluetun-entrypoint" About an hour ago Up About an hour (healthy) 0.0.0.0:7878-7878/tcp, [::]:7878-7878/tcp, 0.0.0.0:8191-8191/tcp, [::]:8191-8191/tcp, 0.0.0.0:8686-8686/tcp, [::]:8686-8686/tcp, 0.0.0.0:8989-8989/tcp, [::]:8989-8989/tcp, 0.0.0.0:8089-8080/tcp, [::]:8089-8080/tcp, 0.0.0.0:8186-8081/tcp, [::]:8186-8081/tcp, 0.0.0.0:8181-9696/tcp, [::]:8181-9696/tcp sb-gluetun root@Rivendell:~ docker logs sb-qbittorrent --tail 40 User UID: 1000 User GID: 1000 ─────────────────────────────────────── Linuxserver.io version: 5.2.0v2.0.12-ls458 Build-date: 2026-05-17T08:57:46+00:00 ─────────────────────────────────────── [custom-init] No custom files found, skipping... [custom-init] No custom services found, skipping... [migrations] started [migrations] no migrations found usermod: no changes ─────────────────────────────────────── ██╗ ███████╗██╗ ██████╗ ██║ ██╔════╝██║██╔═══██╗ ██║ ███████╗██║██║ ██║ ██║ ╚════██║██║██║ ██║ ███████╗███████║██║╚██████╔╝ ╚══════╝╚══════╝╚═╝ ╚═════╝ Brought to you by linuxserver.io ─────────────────────────────────────── To support LSIO projects visit: https://www.linuxserver.io/donate/ ─────────────────────────────────────── GID/UID ─────────────────────────────────────── User UID: 1000 User GID: 1000 ─────────────────────────────────────── Linuxserver.io version: 5.2.0v2.0.12-ls458 Build-date: 2026-05-17T08:57:46+00:00 ─────────────────────────────────────── [custom-init] No custom files found, skipping...
tomspark wrote:
That confirms it: gluetun (the VPN) is healthy and stable, so the problem is qBit alone — it's getting killed before it finishes starting (the log just loops the startup banner and never reaches qBittorrent itself). One command tells us exactly why: docker inspect sb-qbittorrent --format 'exit={{.State.ExitCode}} oom={{.State.OOMKilled}} restarts={{.RestartCount}}' If you see oom=true, that's the answer — WSL2 caps how much memory it hands Linux, and qBit's getting starved (fix is bumping the limit in your Windows .wslconfig). If it's oom=false, qBit's own config likely got scrambled when it was force-stopped, and we'll reset just that one folder. Paste what it shows and I'll give you the exact fix.
hailreaper wrote:
Yep, looks like oom-false in this case. I must have messed up the config when trying to set it up. root@Rivendell:~ docker inspect sb-qbittorrent --format 'exit={{.State.ExitCode}} oom={{.State.OOMKilled}} restarts={{.RestartCount}}' exit=0 oom=false restarts=0
tomspark wrote:
Good — that rules out a memory problem, so we're in good shape. Here's what's actually happening: SparkBox runs a little watchdog that restarts any app it thinks is unhealthy, and on a slower setup it's restarting qBit before qBit finishes waking up — so it never gets to finish and just loops. That's why your log keeps repeating the startup banner and never reaches qBittorrent itself. Let's give it room to breathe — this pauses the watchdog, restarts qBit, waits 2 minutes, then turns the watchdog back on, all in one go: sudo docker stop sb-deunhealth && sudo docker restart sb-qbittorrent && sleep 120 && sudo docker start sb-deunhealth Then open qBit — it should finally load its login page. If it's STILL looping after that, reply and we'll reset its settings file (it likely got half-written when it was force-stopped).
hailreaper wrote:
root@Rivendell:~ sudo docker stop sb-deunhealth && sudo docker restart sb-qbittorrent && sleep 120 && sudo docker start sb-deunhealth sb-deunhealth sb-qbittorrent sb-deunhealth Looks like it did stop Deunhealth and restart it after a delay, but seems that qBit is still stuck in its fun little loop segment despite our best efforts so far
tomspark wrote:
Okay — your dashboard's activity feed told me what I needed: qBit is actually crashing, not just getting restarted. That means its settings file got scrambled when it was force-stopped mid-setup, so qBit chokes the instant it tries to read it. That's your loop — and it lines up with your own hunch. Fix is to give it a clean slate. This sets the old settings aside (fully reversible) and rebuilds qBit fresh: sudo docker stop sb-qbittorrent && sudo mv /opt/sparkbox/modules/media/config/qbittorrent /opt/sparkbox/modules/media/config/qbittorrent.bak && sudo sparkbox up Give it 2-3 minutes — qBit should finally come up and stay healthy, no more loop. Once it's up, try opening it; if your saved password doesn't get you in, just reply and we'll set the login in one quick step (that part's a separate, known thing — not the crash).