qBittorrent and Portainer not working
Posted by niels
Current situation: So I fixed most of the media apps via WSL with the commands: sudo sparkbox down and sudo sparkbox up. But qBittorrent keeps going bad after restart and Portainer uses the wrong port I quess. I hope the reply from the AI gives support team enough information to fix this issue. Reply from the AI: Yeah, my IPv6 theory was wrong. curl -4 failing killed that one. What we know now: Jellyfin 8096 and Seerr 5055 work locally. Portainer itself works on its container IP over 9443. Docker has a proxy process and published mapping for 9000. qBittorrent 8089 has gone bad again after the Docker restart. So this isn’t a general WSL firewall, Tailscale, or Docker-down problem. It’s selective forwarding into Portainer and the Gluetun/qBit namespace. We’ve already done the two safe resets: sparkbox down/up and a Docker-service restart. Don’t start deleting networks or editing Docker firewall rules by hand. Click Share to demox below. Include this exact summary: WSL2 Docker Engine, no Docker Desktop. Working locally: curl -4 -I http://localhost:8096 = Jellyfin 302 curl -4 -I http://localhost:5055 = Seerr 307 Timing out locally: curl -4 -I http://localhost:9000 = timeout curl -4 -I http://localhost:8089 = timeout Portainer container IP HTTPS :9443 returns HTTP 200. Portainer logs say it started HTTP :9000 and HTTPS :9443. docker ps shows 9000 published on sb-portainer and 8089 published on sb-gluetun. Ran sudo sparkbox down && sudo sparkbox up, then sudo systemctl restart docker and sudo sparkbox up. Issue remains. That’s enough for Tom to distinguish a SparkBox compose/publish regression from an odd WSL Docker networking edge case.
4 replies
Chris wrote:
That narrows it down well: localhost:9000 and localhost:8089 timing out while their containers are up points to a WSL port-publishing problem, not a wrong Portainer port. Don’t change ports, Docker networks, or firewall rules. I’ve logged this and our team is investigating. I’ll compare the media and core port-publish setup against the results you posted.
Chris wrote:
Update, niels: you found the fix yourself and posted it in 44133 and your private ticket - disabling networkingMode=mirrored in .wslconfig cleared the selective qBittorrent/Portainer timeouts on this box too. One caveat for the record: that swap also means WSL gets a private 172.x address that only this PC can reach, so if you ever want another device on your LAN to reach these apps directly, the documented alternative is a Hyper-V firewall rule instead of switching modes: Set-NetFirewallHyperVVMSetting -Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -DefaultInboundAction Allow wsl --shutdown Marking this resolved on your report; shout if it comes back.
clodd wrote:
From another thread for the similar behavior, when hyper-v firewall recommendation from sparkbox doctor was insufficient: doing this finally worked for me on windows sudo ufw allow 8089/tcp sudo ufw allow 9000/tcp
Chris wrote:
Thanks clodd — that's a genuinely useful datapoint to keep in this thread. Doctor's Hyper-V rule and your ufw rules sit on opposite sides of the same problem: Set-NetFirewallHyperVVMSetting governs what the Windows host lets into the WSL2 VM, while sudo ufw allow governs what the Linux distro accepts once the traffic is inside. Depending on which layer drops the forwarded packets, one box can need the distro side and another the host side — which is exactly why a box can still be blocked after only one of the two. One heads-up for anyone copying the commands: the ufw allow lifts the block on the qBittorrent WebUI (8089) and Portainer (9000), and on mirrored networking those ports become reachable from other devices on your LAN. Both apps have their own login — keep those passwords set and strong. For PC-only access that's the end of it.