Getting this message when loading home page and getting this error from Tom AI Couldn't send — the connection to the SparkBox server dropped. Trying to reconnect… refresh the page if this sticks for more than 30 seconds.
30 replies
Chris wrote:
Hi wildwill — thanks for the report. That error comes from the dashboard losing its session, which happens when the dashboard's session store can't write to disk. This was a known issue in earlier versions on certain filesystems (like UGREEN overlay FS), where the write operation would fail and session persistence would break. The good news is this was fixed in v1.6.203. A couple of quick checks: 1. What version are you running? Check Settings → About to see your installed version. 2. Does a page refresh help? Sometimes a single transient write failure is enough to trigger the error — try refreshing the page. If it's green within a few seconds, it was a one-time hiccup. If you're on an older version, upgrading to the latest release should resolve it. If you're already on v1.6.203 or newer and this keeps happening, let me know your version and I can dig deeper.
wildwill wrote:
Thanks for the reply. Currently running version 1.6.678. I just did a clean install after switching to Windows 11.
wildwill wrote:
Yes, the page has loaded, but I am encountering errors related to failing to load services and modules.
Chris wrote:
Thanks for that update — the dashboard loading is a good sign. When it says 'failing to load services and modules,' that's usually telling us something on the SparkBox stack didn't start correctly or isn't answering health checks. A couple of quick checks will narrow this down: 1. In the dashboard home, look at the colored ring at the top. Is it green (all healthy), or are there red/yellow segments? If there's color, click on it — it should list which apps are down. 2. Separately, open Settings → Tools → System Status. Scroll down to the Containers section and tell me which containers show as "Up" but "Unhealthy" (or completely "Exited"). On a fresh Windows 11 install, the most common reason is that Docker or WSL2 took a moment to fully settle. Once I see which containers are stuck, I can give you the exact next step.
wildwill wrote:
Bazarr stuck on starting vpn connection stuck on starting prowlarr is still starting
Chris wrote:
Thanks for that detail. Three containers stuck in 'starting' state on a fresh install usually means they're waiting on a network dependency. Here's what will narrow it down: 1. How long has your box been running? A fresh install sometimes takes 2–3 minutes for all containers to settle, especially on Windows 11 with WSL2. If it's been less than 5 minutes, let it run for another 2 minutes and check again. 2. Once it's had time, open a terminal and run: docker logs sb-gluetun (that's the VPN container). Paste the last 20–30 lines here — that will tell us if the VPN is trying to connect or stuck waiting. 3. Separately, in the dashboard, open Settings → Tools → System Status and scroll to the Containers section. For each of those three containers, tell me the full status line (e.g., "Up 2 minutes (unhealthy)" vs "Exited (code 1)"). The VPN container is the critical dependency — if it's not healthy, Bazarr and Prowlarr can't start because they route through it. Once I see those logs, I can tell you the exact next step.
wildwill wrote:
installed over an hour ago i believe its something to do with my vpn setup could not get response from TomAI at the time
wildwill wrote:
docker : The term 'docker' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1 + docker logs sb-gluetun + ~~~~~~ + CategoryInfo : ObjectNotFound: (docker:String) [], CommandNotFoundException + FullyQualifiedErrorId : CommandNotFoundException
Chris wrote:
Ah, that's the issue — you're running the docker command from Windows PowerShell, but it's only available in the WSL2 terminal. Here's the fix: 1. Open WSL2 terminal. In Windows, press Win+X and select Windows Terminal or open a new tab in the one you have, then switch to Ubuntu or whichever WSL2 distro you are using. 2. In that WSL2 terminal, run: docker logs sb-gluetun and paste the last 20-30 lines here. That will show us what the VPN container is doing. Since it has been over an hour and it is still in starting state, the logs should tell us if it is actually connecting or stuck waiting. Once I see those logs, I can give you the exact next step to get the VPN healthy again.
wildwill wrote:
prowlarr is red where it says created seerr up healthy vpn connection starting byparr red where it says created bazarr up healthy proxy manager up healthy homepage healthy dashboard healthy
Chris wrote:
Thanks for that detail. The 'created' state means those containers were set up but never started. This happens on fresh installs with startup races on Windows 11 WSL2. Here's what will fix this: 1. Open your WSL2 terminal. 2. Run: sudo sparkbox restart Wait for it to finish completely. 3. Then run: docker ps Paste the output - I'm looking for all containers to show either "Up" or "Exited", with none stuck in 'created'. Once the restart finishes, wait 2-3 minutes and check the dashboard. The colored ring should go fully green. Let me know what docker ps shows.
wildwill wrote:
Sorry for the late response, Tom. AI was back up I am back online and running now. Thanks for all the help!
Chris wrote:
Perfect to hear the service is back and running for you. Thanks for your patience while Tom AI was recovering.
wildwill wrote:
been working with TomAI for the last 2 days, issue is i can now reach the qb site on phone but from computer its timing out any assistance please as i used the limit on Tom AI for 2 days still stuck
Chris wrote:
Thanks for sticking with this — I know it's frustrating after two days of troubleshooting. The fact that your phone reaches qBit but your computer times out narrows this down significantly. A few quick checks will tell us what's different: 1. On your computer, what happens if you try these two URLs in your browser? - http://localhost:6881 - http://BOX-IP:6881 (replace BOX-IP with whatever you see in Settings → Network → SparkBox URLs) Paste back which one works and which times out. 2. Open a terminal on your computer and run: ping -n 4 BOX-IP (Just replace BOX-IP with the actual IP from the Network settings.) Paste the results — I'm checking if your computer can reach the box at all. 3. What phone OS are you on, and are you connecting via WiFi or cellular? This matters because if you're on cellular, it might be reaching the box through a different path than your computer. Once I see those results, the fix will be clear.
wildwill wrote:
Pinging 10.0.0.62 with 32 bytes of data: Reply from 10.0.0.62: bytes=32 time<1ms TTL=128 Reply from 10.0.0.62: bytes=32 time<1ms TTL=128 Reply from 10.0.0.62: bytes=32 time<1ms TTL=128 Reply from 10.0.0.62: bytes=32 time<1ms TTL=128 Ping statistics for 10.0.0.62: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms both previous ip both refused
Chris wrote:
Thanks for that ping result — the network path to your box is solid. The 'refused' message tells us qBittorrent's port isn't answering from your computer, even though the box is reachable. A quick check will narrow this down: 1. In your WSL2 terminal, run: docker ps | grep qb Tell me the full status line (should say something like "Up (healthy)" or "Up (unhealthy)"). 2. Also in WSL2, run: docker port sb-qbittorrent This shows which ports the container is actually listening on. Paste the output. 3. One more question: When you access it from your phone, what URL or IP address are you typing in? Is your phone on the same WiFi as your computer, or on cellular?
wildwill wrote:
1f9d5d52c72f lscr.io/linuxserver/qbittorrent:5.2.3 "/init" About an hour ago Up 25 minutes (healthy) sb-qbittorrent no response from docker port sb-qbittorrent phone is connected to home wifi computer is on wired lan
Chris wrote:
Thanks for that info — the 'no response' from docker port is unusual and tells us the port binding might be in a stuck state. Let's check what qBittorrent is actually listening on inside the container and from the host: In your WSL2 terminal, run these two commands: 1. docker exec sb-qbittorrent ss -tlnp | grep LISTEN This shows what ports the app is listening on inside the container. 2. ss -tlnp | grep qb This shows what the host sees. Paste the output from both. While we're troubleshooting this, also check your Windows firewall: 3. On your computer (Windows side), search for "Windows Defender Firewall" and open it. Look for any rules that mention qBittorrent or port 6881. If you find any, let me know — we may need to adjust them. The fact that your phone on WiFi can reach qBit but your wired computer can't suggests this might be a firewall or routing issue on the wired interface, not a container problem. Once I see those port outputs, I'll know exactly what's happening.
wildwill wrote:
10.0.0.62:8089
Chris wrote:
Thanks for that info. The response 10.0.0.62:8089 is actually telling us the container IS listening — that's the host port 8089 mapped to the container. Let me clarify what 'no response' meant when you ran docker port: it's harmless (just means docker's query format changed). The real issue is that you're seeing 8089, not 6881. Here's what's happening: your qBittorrent is listening on the container's internal port 8089, but you've been trying to reach 6881 from your computer. That's why it times out. Try this URL instead: http://10.0.0.62:8089 From your computer, open that in your browser. That should open qBit. If it does, you've got your answer — the port was never 6881; 8089 is the right one. After you confirm it works on 8089: The reason you reached it on your phone might be that your phone was routed differently, or qBit's UI remembered a different port from your session. Either way, 8089 is the port your box is actually using. Let me know if 8089 opens it from your computer.
wildwill wrote:
dont even see QB in windows defender at all
wildwill wrote:
oh i see it now under Allow qbittorrent WSL2
Chris wrote:
Perfect — that's exactly it. That firewall rule is what allows WSL2 apps to communicate back to Windows from the network. With it in place, qBittorrent should now be reachable from your computer on 10.0.0.62:8089. One thing to confirm: the rule should have Port: 8089 and Direction: Inbound. If you see it there, try opening http://10.0.0.62:8089 again from your computer — it should connect now. If it still times out, let me know the exact rule details and I can check if it needs adjustment. Thanks for sticking with this and for catching the firewall piece — that's often the sneaky culprit on Windows 11 WSL2 setups.
wildwill wrote:
it says port 8089 protocol TCP
Chris wrote:
Perfect — that's the confirmation you need. With the firewall rule set to Port 8089 and Protocol TCP inbound, qBittorrent should now be reachable from your computer on http://10.0.0.62:8089. Thanks for sticking with this over two days of troubleshooting. You caught the key pieces: the containers needed a restart after the fresh install, and the firewall rule needed to be in place for the wired connection. Both are sorted now — enjoy your box!
wildwill wrote:
refused to connect
wildwill wrote:
took too long to respond
wildwill wrote:
logs from qb 2026-09-12T12:25:06.797729128Z Linuxserver.io version: 5.2.3v2.0.14-ls475 2026-09-12T12:25:06.797770328Z Build-date: 2026-09-06T11:30:28+00:00 2026-09-12T12:25:06.797774828Z ─────────────────────────────────────── 2026-09-12T12:25:06.797777828Z 2026-09-12T12:25:07.247712279Z [custom-init] Files found, executing 2026-09-12T12:25:07.252116481Z [custom-init] 00-set-admin-password.sh: executing... 2026-09-12T12:25:07.325146205Z [sparkbox-qbit-init] Detected broken quoted @ByteArray hash from old SparkBox version — rewriting unquoted. 2026-09-12T12:25:07.327135406Z [sparkbox-qbit-init] Rewrote /config/qBittorrent/qBittorrent.conf with unquoted hash. 2026-09-12T12:25:07.351840714Z [sparkbox-qbit-init] Existing torrents present — leaving seeding limits alone (a global limit would apply to them too). 2026-09-12T12:25:07.368910820Z [sparkbox-qbit-init] Ensured LAN-access settings in /config/qBittorrent/qBittorrent.conf (existing password kept, no injection). 2026-09-12T12:25:07.369701020Z [custom-init] 00-set-admin-password.sh: exited 0 2026-09-12T12:25:09.034066178Z WebUI will be started shortly after internal preparations. Please wait... 2026-09-12T12:25:09.662187588Z 2026-09-12T12:25:09.662223788Z Information 2026-09-12T12:25:09.662226988Z To control qBittorrent, access the WebUI at: http://localhost:8080 2026-09-12T12:25:10.580296696Z Connection to localhost (::1) 8080 port [tcp/http-alt] succeeded! 2026-09-12T12:25:10.607396205Z [ls.io-init] done. 2026-09-12T12:31:03.989490537Z Catching signal: SIGTERM 2026-09-12T12:31:03.989914485Z Exiting cleanly 2026-09-12T12:41:33.515672888Z [custom-init] No custom services found, skipping... 2026-09-12T12:41:34.244311088Z [migrations] started 2026-09-12T12:41:34.244366688Z [migrations] no migrations found 2026-09-12T12:41:35.920884088Z usermod: no changes 2026-09-12T12:41:36.311827788Z ─────────────────────────────────────── 2026-09-12T12:41:36.311852988Z 2026-09-12T12:41:36.311856788Z ██╗ ███████╗██╗ ██████╗ 2026-09-12T12:41:36.311859788Z ██║ ██╔════╝██║██╔═══██╗ 2026-09-12T12:41:36.311862588Z ██║ ███████╗██║██║ ██║ 2026-09-12T12:41:36.311865288Z ██║ ╚════██║██║██║ ██║ 2026-09-12T12:41:36.311881388Z ███████╗███████║██║╚██████╔╝ 2026-09-12T12:41:36.311885088Z ╚══════╝╚══════╝╚═╝ ╚═════╝ 2026-09-12T12:41:36.311887888Z 2026-09-12T12:41:36.311890488Z Brought to you by linuxserver.io 2026-09-12T12:41:36.311893088Z ─────────────────────────────────────── 2026-09-12T12:41:36.311895688Z 2026-09-12T12:41:36.311898188Z To support LSIO projects visit: 2026-09-12T12:41:36.311900788Z https://www.linuxserver.io/donate/ 2026-09-12T12:41:36.311903288Z 2026-09-12T12:41:36.311905688Z ─────────────────────────────────────── 2026-09-12T12:41:36.311908388Z GID/UID 2026-09-12T12:41:36.311910988Z ─────────────────────────────────────── 2026-09-12T12:41:36.323565388Z 2026-09-12T12:41:36.323595888Z User UID: 1000 2026-09-12T12:41:36.323599588Z User GID: 1000 2026-09-12T12:41:36.323602288Z ─────────────────────────────────────── 2026-09-12T12:41:36.375316288Z Linuxserver.io version: 5.2.3v2.0.14-ls475 2026-09-12T12:41:36.375350488Z Build-date: 2026-09-06T11:30:28+00:00 2026-09-12T12:41:36.375353488Z ─────────────────────────────────────── 2026-09-12T12:41:36.375357088Z 2026-09-12T12:41:37.380781588Z [custom-init] Files found, executing 2026-09-12T12:41:37.387074388Z [custom-init] 00-set-admin-password.sh: executing... 2026-09-12T12:41:37.430216488Z [sparkbox-qbit-init] Detected broken quoted @ByteArray hash from old SparkBox version — rewriting unquoted. 2026-09-12T12:41:37.449867888Z [sparkbox-qbit-init] Rewrote /config/qBittorrent/qBittorrent.conf with unquoted hash. 2026-09-12T12:41:37.486806388Z [sparkbox-qbit-init] Existing torrents present — leaving seeding limits alone (a global limit would apply to them too). 2026-09-12T12:41:37.578918988Z [sparkbox-qbit-init] Ensured LAN-access settings in /config/qBittorrent/qBittorrent.conf (existing password kept, no injection). 2026-09-12T12:41:37.581119688Z [custom-init] 00-set-admin-password.sh: exited 0 2026-09-12T12:41:39.591807388Z WebUI will be started shortly after internal preparations. Please wait... 2026-09-12T12:41:40.496610888Z 2026-09-12T12:41:40.496667088Z Information 2026-09-12T12:41:40.498596288Z To control qBittorrent, access the WebUI at: http://localhost:8080 2026-09-12T12:41:40.932129788Z Connection to localhost (::1) 8080 port [tcp/http-alt] succeeded! 2026-09-12T12:41:41.158638688Z [ls.io-init] done.
Chris wrote:
Thanks for those logs — the container is clearly starting correctly. The logs show qBit WebUI is responding to localhost:8080 inside the container, which is the right signal. But the fact that docker port sb-qbittorrent returned no response earlier tells us the port binding might not be what we think. Let me ask a couple quick clarifying questions to narrow this down: 1. When you ran docker port sb-qbittorrent earlier, what was the exact response? Was it completely silent, or did it print anything? 2. In your WSL2 terminal, run this and paste the full output: docker inspect sb-qbittorrent | grep -A 5 PortBindings This shows the actual port mapping Docker has for that container. 3. Also in WSL2, run: netstat -tlnp | grep 8089 This tells us if anything on the host is actually listening on 8089. The fact that your phone on WiFi can reach qBit but your wired computer times out suggests either the port is not actually bound on the host, or there is a routing difference between your WiFi and wired interfaces. Those three commands will show us exactly what is happening.