Pretty new to this so I apologize if this is easier than I seem to be making it. I was able to get SparkBox up and running and was finally able to access the dashboard and install the "Media Center" suite, but however I am now not able to access any of the apps with each one displaying a "This site can’t be reached" error with "YOURSERVERIP took too long to respond". I ran a sudo sparkbox doctor and the only finding was a port conflict for port 53 being in use by a non-docker process. According to the documentation this is commonly for dnsmasq, but I can't find anything confirming that to be the case. I am currently using a WSL2 VPS setup and running ProtonVPN with WireGuard and also tried changing server countries to no avail. Kind of hit a wall at this point and not really sure what to do next as I don't want to break anything messing around with port configs by accident.
11 replies
tomspark wrote:
That's the one — love it. 🎉 Quick tip: bookmark those localhost addresses and you're all set. Enjoy the build!
tomspark wrote:
Port 53 conflict is the culprit — your media services can't resolve DNS so everything times out. On WSL2, dnsmasq or systemd-resolved is usually holding it. Run sudo lsof -i :53 to see what process owns it, then kill it: sudo systemctl stop systemd-resolved (if that's the one) or sudo killall dnsmasq. After that, sudo sparkbox restart media and the services should come up. If systemd-resolved keeps auto-restarting on reboot, edit /etc/systemd/resolved.conf, set DNSStubListener=no, save, then sudo systemctl restart systemd-resolved. Pi-hole needs port 53 free to act as your DNS server — once it's running the dashboard will show zero blocked queries until you point your router (or just this WSL2 instance) at the NAS as DNS, but the media apps themselves don't need that — they just need the port free so Docker can bind it. ProtonVPN + WireGuard is fine for the media stack; the country-switching you tried was the right instinct if indexers were failing, but that's a separate issue from this timeout. Get port 53 clear and report back if the services still won't start.
hailreaper wrote:
That is one of the weird things about it, lsof doesn't seem to see what is on :53 at all and it also acts like dnsmasq doesn't exist. root@Rivendell:~ sudo lsof -i :53 root@Rivendell:~ sudo killall dnsmasq dnsmasq: no process found Not sure if it would be any correlation or not, but I also have noticed that 3 of the services are showing "Unhealthy" now: Bazarr qBittorrent Sonarr All of them when I select Resume throw a "Container not found" error, however they were all healthy and up earlier in the day.
tomspark wrote:
The "Container not found" errors mean those three containers crashed and Docker can't find them to restart — run docker ps -a | grep -E 'bazarr|qbittorrent|sonarr' and paste the output so I can see their actual state, then we'll force-recreate them with sparkbox up.
hailreaper wrote:
root@Rivendell:~ docker ps -a | grep -E 'bazarr|qbittorrent|sonarr' 19dd927732e8 lscr.io/linuxserver/qbittorrent:5.2.0 "/init" 13 hours ago Up 13 hours (healthy) sb-qbittorrent fcbd2f214d35 lscr.io/linuxserver/sonarr:4.0.17 "/init" 13 hours ago Up 21 seconds (healthy) sb-sonarr 1526a1caee33 lscr.io/linuxserver/bazarr:1.5.6 "/init" 13 hours ago Up 13 hours (healthy) 0.0.0.0:6767-6767/tcp, [::]:6767-6767/tcp sb-bazarr
tomspark wrote:
Good news first: those three apps aren't broken — your output shows all of them Up and healthy (Sonarr just restarted itself), so that scare has passed. And you can ignore the port 53 finding — that one only matters if you're running Pi-hole, not your media apps. The real difference: your media apps all run behind SparkBox's built-in VPN, which is why the dashboard loads fine but the apps time out. So we need to check whether that VPN is passing traffic. Run this and paste what it shows: docker logs sb-gluetun --tail 30 One hunch — you're running ProtonVPN on the machine itself AND SparkBox runs its own VPN inside; on WSL2 those two can clash over network routing. That log will tell us which way to go.
hailreaper wrote:
I do run ProtonVPN on my device and had thought that might be playing into it but even after disabling it I can't seem to reach any of the apps outside of the Dashboard itself. root@Rivendell:~ docker logs sb-gluetun --tail 30 | ├── ip2location | └── cloudflare └── Version settings: └── Enabled: yes 2026-05-24T15:28:22Z INFO [routing] default route found: interface eth0, gateway 172.20.4.1, assigned IP 172.20.4.3 and family v4 2026-05-24T15:28:22Z INFO [routing] adding route for 0.0.0.0/0 2026-05-24T15:28:22Z INFO [firewall] setting allowed subnets... 2026-05-24T15:28:22Z INFO [routing] default route found: interface eth0, gateway 172.20.4.1, assigned IP 172.20.4.3 and family v4 2026-05-24T15:28:22Z INFO [routing] adding route for 192.168.0.0/16 2026-05-24T15:28:22Z INFO [routing] adding route for 10.0.0.0/8 2026-05-24T15:28:22Z INFO [routing] adding route for 172.16.0.0/12 2026-05-24T15:28:22Z INFO [firewall] setting allowed input port 8989 through interface eth0... 2026-05-24T15:28:22Z INFO [firewall] setting allowed input port 7878 through interface eth0... 2026-05-24T15:28:22Z INFO [firewall] setting allowed input port 9696 through interface eth0... 2026-05-24T15:28:22Z INFO [firewall] setting allowed input port 8686 through interface eth0... 2026-05-24T15:28:22Z INFO [firewall] setting allowed input port 8080 through interface eth0... 2026-05-24T15:28:22Z INFO [firewall] setting allowed input port 8191 through interface eth0... 2026-05-24T15:28:22Z INFO [firewall] setting allowed input port 6767 through interface eth0... 2026-05-24T15:28:22Z INFO [dns] using plaintext DNS at address 1.1.1.1 2026-05-24T15:28:22Z INFO [healthcheck] listening on 127.0.0.1:9999 2026-05-24T15:28:22Z INFO [http server] http server listening on [::]:8000 2026-05-24T15:28:22Z INFO [firewall] allowing VPN connection... 2026-05-24T15:28:22Z INFO [wireguard] Using available kernelspace implementation 2026-05-24T15:28:22Z INFO [wireguard] Connecting to 89.222.103.6:51820 2026-05-24T15:28:22Z INFO [wireguard] Wireguard setup is complete. Note Wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the Wireguard connection is not working. 2026-05-24T15:28:27Z INFO [dns] downloading hostnames and IP block lists 2026-05-24T15:28:27Z INFO [dns] DNS server listening on [::]:53 2026-05-24T15:28:27Z INFO [dns] ready 2026-05-24T15:28:27Z INFO [ip getter] Public IP address is 185.98.168.90 (United States, Georgia, Atlanta - source: ipinfo+ifconfig.co+ip2location+cloudflare) 2026-05-24T15:28:28Z INFO [vpn] You are running the latest release v3.41.1
tomspark wrote:
That log is actually great news: your VPN is healthy — it connected, pulled a public IP, and opened all the app ports. So the VPN's not the problem (and leaving ProtonVPN on or off is fine). The apps are up too. So the only question left is whether the box can reach its own apps. From that same terminal, run: curl -I http://localhost:8989 If you get any response (even "401 Unauthorized"), the app's reachable and the issue is just how your browser is getting there — so tell me how you open the apps: clicking the tiles in the dashboard, or typing an address? And what address shows? If instead it just hangs, paste that. One quick heads-up: in SparkBox qBittorrent is on port 8089, not the usual 8080 — so if you tried 8080, that one's expected to fail.
hailreaper wrote:
root@Rivendell:~ curl -I http://localhost:8989 HTTP/1.1 401 Unauthorized Date: Sun, 24 May 2026 15:55:19 GMT Server: Kestrel I have tried both clicking the tile in the dashboard and also typing in the address manually. I was curious if my Browser was causing the issue (Brave) so I attempted using Firefox and Chrome but it didn't have any change when using a different browser. The address that shows is http://MYSERVERIP:8181/ The error that populates on the page is: "This site can’t be reached MYSERVERIP took too long to respond. Try: Checking the connection Checking the proxy and the firewall ERRCONNECTIONTIMEDOUT" I did confirm qBittorrent is using the correct port of 8089 so that doesn't seem to be what is impacting that app specifically
tomspark wrote:
That 401 is exactly what we wanted to see — Sonarr's alive and reachable right there on the box, nothing's broken. The whole problem is just the address. On a WSL2 setup, your Windows browser can only reach the box through "localhost" — the MYSERVERIP address the dashboard hands you isn't reachable from Windows, so it times out. (Your dashboard loads because you're opening it via localhost.) So just swap the IP for localhost in your browser: http://localhost:8181 for Prowlarr, http://localhost:8989 Sonarr, http://localhost:7878 Radarr, http://localhost:8089 qBittorrent. They'll load right up. The tiles handing you the box's IP instead of localhost is a known rough edge for WSL2 — I'm flagging it to smooth out. Let me know those open!
hailreaper wrote:
Wow! Thank you so much, it loaded up instantly using localhost! I appreciate all of your help!