Hi, just want to disclaim this is my first time posting on a public forum so I apologise if its not very clear. I was having issues with qbittorrent failing to load (localhost:8089) and after several hours of trying to make it work with Claude - I eventually reached a point where I ran sudo sparkbox doctor, a few steps later this message popped up with a recommendation to post it here. This is my first time trying to use anything like Sparkbox but it seems like everything I want and I'm trying very hard to make it work lol. I also know that getting the supporter tier probably would fix these issues very fast but struggling a little financially so will consider it in the future (if I can make this work) [ERROR] Portainer is up but login still failed (last HTTP: 000). This shouldn't happen after a clean wipe — check 'docker logs sb-portainer' and report back at https://demox.world/d/sparkbox with the log output. root@DESKTOP-EAVM0GC:~ docker logs sb-portainer 2026/08/10 09:29PM INF github.com/portainer/portainer/api/cmd/portainer/main.go:358 encryption key file not present | filename=/run/secrets/portainer 2026/08/10 09:29PM INF github.com/portainer/portainer/api/cmd/portainer/main.go:396 proceeding without encryption key | 2026/08/10 09:29PM INF github.com/portainer/portainer/api/database/boltdb/db.go:163 loading PortainerDB | filename=portainer.db 2026/08/10 09:29PM INF github.com/portainer/portainer/api/internal/ssl/ssl.go:79 no cert files found, generating self signed SSL certificates | 2026/08/10 09:29PM INF github.com/portainer/portainer/api/cmd/portainer/main.go:540 created admin user with the given password. | 2026/08/10 09:29PM INF github.com/portainer/portainer/api/chisel/service.go:227 generated a new Chisel private key file | private-key=/data/chisel/private-key.pem 2026/08/10 21:29:54 server: Reverse tunnelling enabled 2026/08/10 21:29:54 server: Fingerprint hCoBDNZnTXIqa5pSaEtbAtP40aIavgQ2XTSyFJlD/Fo= 2026/08/10 21:29:54 server: Listening on http:// 0.0 .0.0:8000 2026/08/10 09:29PM INF github.com/portainer/portainer/api/cmd/portainer/main.go:686 starting Portainer | buildnumber=27 goversion=go1.26.4 imagetag=2.43.0-linux-amd64 nodejsversion=v22.22.3 pnpmversion=10.27.0 version=2.43.0 webpackversion=5.107.2 2026/08/10 09:29PM INF github.com/portainer/portainer/api/http/server.go:366 starting HTTPS server | bindaddress=:9443 2026/08/10 09:29PM INF github.com/portainer/portainer/api/http/server.go:350 starting HTTP server | bindaddress=:9000~ (space between the 0.0 .0.0:8000 due to the flagging)
12 replies
Chris wrote:
Welcome, and don't apologise — that's a good report. You posted the one log that answers it. Portainer is fine: your log shows it booted and created the admin user. What failed is SparkBox reaching it on 127.0.0.1, and that's likely the same reason qBittorrent wouldn't load on localhost:8089. On Windows, WSL sometimes stops passing 127.0.0.1 traffic through to things that are listening — every local address hangs while the apps themselves are healthy. Try this first: open PowerShell on Windows and run wsl --shutdown, then reopen your SparkBox terminal. It closes your WSL windows and resets that networking layer; nothing is lost. Tom also shipped v1.6.546 today, which waits far longer on Windows before giving up here. Grab it with sudo sparkbox upgrade, then run sudo sparkbox repair-portainer again.
fireballe123 wrote:
Hi, I followed your instructions to shutdown and update, the portainer fails to login as shown below: [INFO] Stopping sb-portainer... [INFO] Wiping /opt/sparkbox/modules/core/config/portainer... [OK] New admin password written to /opt/sparkbox/state/portainer-admin-password.txt [INFO] Starting sb-portainer with new credentials... [INFO] Verifying admin login against http://127.0.0.1:9000/api/auth... [ERROR] Portainer is up but login still failed (last HTTP: 000). Portainer's container looks fine (check with 'docker logs sb-portainer'), but nothing on this WSL box could reach 127.0.0.1:9000 at all. That's a Windows/WSL2 port-forwarding lag after a fresh container, not a broken login. Wait 30-60s and try again: sudo sparkbox repair-portainer If it still fails every time, running Docker Engine inside this WSL distro (instead of Docker Desktop) avoids the lag — guide: https://tomsparkbox.com/guides/run-sparkbox-on-windows-wsl I also followed the instructions and followed the guide for "run sparkbox on windows wsl" as suggested however after all of that it still not working. Same for localhost:8089/qbittorrent still. I did want to mention that on the sparkbox the "TomSparkBox Dashboard" has failed to run when looking at it from the apps page. I am unsure if this is relevent but wanted to mention it.
Chris wrote:
Thanks for the extra detail — sorry this is still not sorted out after the update. Since Portainer, qBittorrent, AND the Dashboard app are all unreachable now, this looks bigger than the Portainer-specific lag we just fixed — more like a host-level WSL2/Docker networking issue on this particular machine. I don't want to guess at a fix here, so could you run sudo sparkbox doctor and paste the full output? It has WSL-specific checks (reachability, port conflicts) that should point at what's actually going on. I'm flagging this thread to Tom in the meantime so he knows it's still open.
fireballe123 wrote:
[Install location] [OK] SparkBox is installed at: /opt/sparkbox [OK] Settings file (.env): /opt/sparkbox/.env [OK] Media library folder (MEDIAROOT): /opt/sparkbox/data/media [Docker] [OK] Docker daemon is accessible [OK] Docker version: Docker version 29.7.2, build a7dcaa6 [OK] Docker Compose: 5.4.0 [Docker Socket] [OK] Docker socket exists at /var/run/docker.sock [OK] Docker socket is readable [User IDs] [INFO] Current user: root (UID=0, GID=0) [OK] PUID=1000 (containers run as UID 1000) [OK] PGID=1000 (containers run as GID 1000) [Container Egress] [OK] Apps can reach webhook.tomsparkbox.com over sbproxy (their real network) [OK] Docker's default bridge can reach tomsparkbox.com (dashboard Update button) [Port Conflicts] [OK] Port 80: in use (Docker -- likely SparkBox) [OK] Port 443: in use by SparkBox (sb-npm) [OK] Port 8443: in use by SparkBox (sb-dashboard) [OK] Port 9000: in use by SparkBox (sb-portainer) [Portainer Auth] [WARN] Portainer not responding at http://127.0.0.1:9000 — may still be starting [VPN Tunnel] [OK] Gluetun tunnel is healthy [Hardware Transcoding] [WARN] Hardware Transcoding is set to 'auto' but this host has NO /dev/dri -- there is no GPU for SparkBox to pass through, so everything transcodes in software This is a HOST setting, not a SparkBox one. On a generic Debian/Ubuntu install the Intel driver may not be loaded: lsmod | grep -c i915 0 means the driver is not loaded sudo apt install firmware-misc-nonfree intel-media-va-driver-non-free sudo modprobe i915 && ls -l /dev/dri On a NAS, enable GPU passthrough for Docker in the NAS settings. If this box genuinely has no usable GPU, set Hardware Transcoding to 'none' in Settings so the dashboard stops implying it is active. [Media Storage] [OK] MEDIAROOT=/opt/sparkbox/data/media exists [OK] MEDIAROOT is writable [OK] Your apps (user id 1000) can read your media library [INFO] Free space at MEDIAROOT: 944GB [System Resources] [INFO] Total RAM: 32223MB [INFO] Available RAM: 29772MB [OK] RAM looks sufficient for 3 enabled modules [INFO] Free disk at SBROOT: 944GB [Container Health] [OK] All SparkBox containers are running and passing their health checks [Windows (WSL) Networking] [OK] Running on Windows (WSL) with 192. — a real home-network address, so other devices can reach this box ============================================ 1 issue(s) found. Review warnings above and fix as needed. ============================================
Chris wrote:
That full report is actually good news: VPN tunnel healthy, no port conflicts, and all containers passing health checks — so this isn't the wider host-network breakdown I was worried about. It's narrowed back to just localhost not connecting from this WSL box, the same quirk as before. One targeted test: from the Windows browser itself (not the WSL terminal), try http://localhost:9000 and http://localhost:8089 directly — WSL2's port-forwarding to Windows and its own internal loopback are handled separately, so localhost from the browser can work even when the WSL-side check fails. Let me know what those two give you and I'll keep this updated for Tom.
fireballe123 wrote:
Neither of those websites loaded - tested on both firefox and chrome sadly :(
Chris wrote:
That rules out the port-forwarding-lag theory — if the Windows browser itself can't reach localhost:9000 or :8089, this isn't a wait-and-retry timing issue anymore. One more thing worth trying: swap localhost for the LAN address doctor printed for you, http://192.168.1.130:9000 and http://192.168.1.130:8089. WSL's loopback and its regular network path are handled separately, so a real address sometimes gets through when localhost won't. If that still doesn't load, this looks like a deeper WSL networking fault on this specific box rather than anything SparkBox is doing wrong, and I don't want to keep guessing — I'm flagging this directly to Tom now.
fireballe123 wrote:
Yes that also didn't work sadly - Open to any more ideas or from Tom
Chris wrote:
Straight answer: what you're hitting matches a known WSL2 fault where 'mirrored' networking mode (the default our Windows installer sets) can leave listening ports totally unreachable from Windows, even by LAN IP, and a wsl --shutdown doesn't reliably clear it. There isn't a confirmed fix yet, so I don't want to keep sending you diagnostics that won't land. One thing worth trying on your own: open %UserProfile%\.wslconfig, switch networkingMode away from mirrored (or delete that line), then wsl --shutdown and relaunch. I've put this specific case in front of Tom directly for a real answer, not just a flag this time — I'll update this thread once I hear back.
Chris wrote:
Tom traced this — it's a known WSL mirrored-networking fault, and there's a safe fix. In an Admin PowerShell: run Get-NetFirewallHyperVVMSetting; if DefaultInboundAction shows Block, run Set-NetFirewallHyperVVMSetting -Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -DefaultInboundAction Allow, then wsl --shutdown, wait 10s, and reopen SparkBox. A VPN app can flip that setting again later — same two commands fix it then too. Still stuck? A full Windows restart (not just wsl --shutdown) cleared it on our own test box. Last resort: in .wslconfig change networkingMode=mirrored to networkingMode=NAT, then wsl --shutdown — that gets the Windows browser working, though other devices on your network won't reach the server until you switch back. A permanent fix is queued.
fireballe123 wrote:
Thank you so much that worked! Just to clarify the steps I took - I followed everything you said to do and none of it worked until I changed the networkingMode=NAT and that fixed it. Have a good rest of your day and thank you for the help Chris
Chris wrote:
Glad that's sorted, and thanks for coming back to share what actually worked -- that's genuinely useful. If the firewall change doesn't do it for someone else hitting this, swapping networkingMode to NAT is a good fallback to try. Enjoy the setup!