My question: I can't access the Dashboard from any other device. Reinstalled Tailscale to get this message: Tailscale. is installed but not running yet It is switched on but has not come up. Check the Containers page or ask Tom AI. Also, these containers need attention on my SparkBox: syncthing (stopped). What's wrong and can you fix them? The dashboard is also stuck again and keeps showing unhealthy. What's going on?unhealthy SparkBox AI replied: Found it. Since switching to mirrored mode already broke Gluetun's route for you, the safe path is the NAT-mode fallback SparkBox already ships: run sudo sparkbox urls (read-only, no config changes). On a Windows/WSL box it now prints a "Windows (WSL) Networking" section with the exact netsh interface portproxy and New-NetFirewallRule commands for your current WSL IP and app ports — that forwards the TV/console traffic from your PC's real LAN address into WSL without touching mirrored mode or Gluetun. One caveat baked into that same output: the WSL IP changes on every Windows restart, so the portproxy line has to be re-run after a reboot. Point the TV at your PC's normal home-network IP (ipconfig in PowerShell), not the WSL address. (From an answered community thread: https://demox.world/post/44052) (Answered instantly from the SparkBox knowledge base — if this doesn't quite match your situation, just say so and I'll take a proper look.) What I still need help with: (describe what didn't work or what's st …(reply truncated — full chat sent to Tom) AI is no longer working, either. Is this the start of the apocalypse?
8 replies
Chris wrote:
Hi 1ye — sorry you're dealing with all of this at once. Quick expectation first: I can't change anything on your box from here; I'll walk you through it. And nothing below changes any settings — these are all read-only checks so we can see what's actually going on before touching anything. Here's the thing worth knowing: when several things fail at the same time (dashboard unhealthy, Tailscale not coming up, syncthing stopped, the AI chat down), that's usually not a bunch of separate random breakages — it's normally one thing underneath (the container runtime or the box's networking) taking several services down together. So let's find that one thing instead of patching each symptom one by one. Please don't disable / re-enable or reinstall Tailscale again while we look — each recreate adds a fresh restart that muddies the logs (we went round that loop on your earlier thread too). Please run these in order and paste the output. They're all safe: 1) sudo sparkbox version Just confirms which version the box is on now. 2) sudo sparkbox status This lists every SparkBox container and flags the ones that are NOT running. The most important part is if it prints a line like "These apps are NOT running: ..." — paste that whole line. 3) sudo docker logs sb-tailscale --tail 30 Recent Tailscale boot lines. The "installed but not running yet" message usually means it never finished signing in (the auth key is missing or expired after a reinstall). We'll see it here. 4) sudo docker logs sb-dashboard --tail 30 Recent dashboard boot lines — tells us why it's reporting unhealthy. Paste those four outputs here and I'll tell you exactly what to do next. We'll take it one step at a time from there. — Chris
1ye wrote:
Alright, here goes-- 1) sudo sparkbox version: SparkBox v1.6.670 2) sudo sparkbox status: sb-syncthing Created [WARN] These apps are NOT running: syncthing 3) sudo docker logs sb-tailscale --tail 30: 2026/09/10 12:45:16 derphttp.Client.Recv: connecting to derp-17 (lax) 2026/09/10 12:45:17 magicsock: derp-17 connected; connGen=234 2026/09/10 12:45:18 logtail: upload: log upload of 436 bytes compressed failed: Post "https://log.tailscale.com/c/tailnode.log.tailscale.io/9007bfcf82e5814fd94cb535f8e66b033f89433f61b2e09e3f54e434660e647d": EOF 2026/09/10 12:46:15 logtail: upload succeeded after 1 failures and 57s 2026/09/10 12:46:17 magicsock: [0x28e4ab4e2c0] derp.Recv(derp-17): derp.Recv: EOF 2026/09/10 12:46:17 derphttp.Client.Recv: connecting to derp-17 (lax) 2026/09/10 12:46:17 magicsock: derp-17 connected; connGen=235 2026/09/10 12:47:17 magicsock: [0x28e4ab4e2c0] derp.Recv(derp-17): derp.Recv: EOF 2026/09/10 12:47:17 derphttp.Client.Recv: connecting to derp-17 (lax) 2026/09/10 12:47:18 magicsock: derp-17 connected; connGen=236 2026/09/10 12:47:24 netcheck: DetectCaptivePortal(found=false) 2026/09/10 12:48:18 magicsock: [0x28e4ab4e2c0] derp.Recv(derp-17): derp.Recv: EOF 2026/09/10 12:48:18 derphttp.Client.Recv: connecting to derp-17 (lax) 2026/09/10 12:48:18 magicsock: derp-17 connected; connGen=237 2026/09/10 12:49:18 magicsock: [0x28e4ab4e2c0] derp.Recv(derp-17): derp.Recv: EOF 2026/09/10 12:49:18 derphttp.Client.Recv: connecting to derp-17 (lax) 2026/09/10 12:49:19 magicsock: derp-17 connected; connGen=238 2026/09/10 12:50:19 magicsock: [0x28e4ab4e2c0] derp.Recv(derp-17): derp.Recv: EOF 2026/09/10 12:50:19 derphttp.Client.Recv: connecting to derp-17 (lax) 2026/09/10 12:50:20 magicsock: derp-17 connected; connGen=239 2026/09/10 12:51:20 magicsock: [0x28e4ab4e2c0] derp.Recv(derp-17): derp.Recv: EOF 2026/09/10 12:51:20 derphttp.Client.Recv: connecting to derp-17 (lax) 2026/09/10 12:51:20 magicsock: derp-17 connected; connGen=240 2026/09/10 12:52:20 magicsock: [0x28e4ab4e2c0] derp.Recv(derp-17): derp.Recv: EOF 2026/09/10 12:52:20 derphttp.Client.Recv: connecting to derp-17 (lax) 2026/09/10 12:52:21 magicsock: derp-17 connected; connGen=241 2026/09/10 12:52:26 netcheck: DetectCaptivePortal(found=false) 2026/09/10 12:53:21 magicsock: [0x28e4ab4e2c0] derp.Recv(derp-17): derp.Recv: EOF 2026/09/10 12:53:21 derphttp.Client.Recv: connecting to derp-17 (lax) 2026/09/10 12:53:22 magicsock: derp-17 connected; connGen=242 4) sudo docker logs sb-dashboard --tail 30: [2026-09-10T10:51:56.806Z] [INFO] License cache refreshed: licensed (Pro) [2026-09-10T10:56:56.806Z] [INFO] License cache refreshed: licensed (Pro) [2026-09-10T11:01:56.884Z] [INFO] License cache refreshed: licensed (Pro) [2026-09-10T11:06:56.781Z] [INFO] License cache refreshed: licensed (Pro) [sessions] Reaped 1 expired session files [2026-09-10T11:12:04.842Z] [INFO] License cache refreshed: licensed (Pro) [alerts] sb-byparr recovered [2026-09-10T11:16:56.854Z] [INFO] License cache refreshed: licensed (Pro) [2026-09-10T11:21:56.826Z] [INFO] License cache refreshed: licensed (Pro) [2026-09-10T11:26:57.001Z] [INFO] License cache refreshed: licensed (Pro) [2026-09-10T11:31:57.193Z] [INFO] License cache refreshed: licensed (Pro) [sessions] Reaped 58 expired session files [2026-09-10T11:36:56.904Z] [INFO] License cache refreshed: licensed (Pro) [2026-09-10T11:41:56.853Z] [INFO] License cache refreshed: licensed (Pro) [2026-09-10T11:46:57.481Z] [INFO] License cache refreshed: licensed (Pro) [2026-09-10T11:51:56.965Z] [INFO] License cache refreshed: licensed (Pro) [2026-09-10T11:56:57.771Z] [INFO] License cache refreshed: licensed (Pro) [2026-09-10T12:01:57.548Z] [INFO] License cache refreshed: licensed (Pro) [sessions] Reaped 57 expired session files [2026-09-10T12:06:57.255Z] [INFO] License cache refreshed: licensed (Pro) [2026-09-10T12:11:57.230Z] [INFO] License cache refreshed: licensed (Pro) [2026-09-10T12:16:57.328Z] [INFO] License cache refreshed: licensed (Pro) [2026-09-10T12:21:57.375Z] [INFO] License cache refreshed: licensed (Pro) [2026-09-10T12:26:57.297Z] [INFO] License cache refreshed: licensed (Pro) [2026-09-10T12:31:57.454Z] [INFO] License cache refreshed: licensed (Pro) [sessions] Reaped 54 expired session files [2026-09-10T12:36:57.342Z] [INFO] License cache refreshed: licensed (Pro) [2026-09-10T12:41:57.479Z] [INFO] License cache refreshed: licensed (Pro) [2026-09-10T12:46:57.513Z] [INFO] License cache refreshed: licensed (Pro) [2026-09-10T12:51:57.447Z] [INFO] License cache refreshed: licensed (Pro) Where to from here?
Chris wrote:
Hi 1ye — good news first: your diagnostics show Tailscale IS working and the serve config IS properly set up. The serve status shows your dashboard IS being published over Tailscale right now. Here is what the output tells us: your Tailscale container IS signed in to your tailnet, and the serve config IS active and correct. The DERP reconnects with EOF errors are just normal network hiccups over a home connection — they do not indicate failure. The three issues you listed are probably one root cause on the CLIENT side, not the box: - Dashboard unhealthy: logs show it is actually running fine. That red label is stale. - Cannot access from other devices: Tailscale IS serving, but your client device might have a stale IP, or there is a firewall blocking the connection on your home network. - Syncthing stopped: this IS real — the container is not running. Is it disabled in your app list, or did it crash? Run: sudo docker logs sb-syncthing | tail -20 and paste the output. Next: rule out the Tailscale path. On the device trying to reach the dashboard: 1. Open Tailscale there and confirm the SparkBox shows in the device list 2. Copy the SparkBox tailnet IP and ping it 3. If ping works, try: curl https://[that-IP]:8443 (ignore cert errors, we just want the connection to reach) Paste those results and we will know if the network path is open.
1ye wrote:
From sudo docker logs sb-syncthing | tail -20 this came up: Connection to localhost (::1) 8384 port [tcp/] succeeded! Connection to localhost (::1) 8384 port [tcp/] succeeded! 2026-09-12 19:15:57 INF Relay listener shutting down (id=dynamic+https://relays.syncthing.net/endpoint log.pkg=connections) 2026-09-12 19:15:57 WRN Service failed (error="Get \"https://relays.syncthing.net/endpoint\": dial tcp: lookup relays.syncthing.net on 8.8.8.8:53: dial udp 8.8.8.8:53: connect: network is unreachable" supervisor=listenerSupervisor@dynamic+https://relays.syncthing.net/endpoint service=dynamic+https://relays.syncthing.net/endpoint log.pkg=connections) 2026-09-12 19:17:16 INF Relay listener starting (id=dynamic+https://relays.syncthing.net/endpoint log.pkg=connections) 2026-09-12 19:17:16 INF Relay listener shutting down (id=dynamic+https://relays.syncthing.net/endpoint log.pkg=connections) 2026-09-12 19:17:16 WRN Service failed (error="Get \"https://relays.syncthing.net/endpoint\": dial tcp: lookup relays.syncthing.net on 8.8.8.8:53: dial udp 8.8.8.8:53: connect: network is unreachable" supervisor=listenerSupervisor@dynamic+https://relays.syncthing.net/endpoint service=dynamic+https://relays.syncthing.net/endpoint log.pkg=connections) 2026-09-12 19:17:16 INF Relay listener starting (id=dynamic+https://relays.syncthing.net/endpoint log.pkg=connections) 2026-09-12 19:17:16 INF Relay listener shutting down (id=dynamic+https://relays.syncthing.net/endpoint log.pkg=connections) 2026-09-12 19:17:16 WRN Service failed (error="Get \"https://relays.syncthing.net/endpoint\": dial tcp: lookup relays.syncthing.net on 8.8.8.8:53: dial udp 8.8.8.8:53: connect: network is unreachable" supervisor=listenerSupervisor@dynamic+https://relays.syncthing.net/endpoint service=dynamic+https://relays.syncthing.net/endpoint log.pkg=connections) 2026-09-12 19:17:16 INF Relay listener starting (id=dynamic+https://relays.syncthing.net/endpoint log.pkg=connections) 2026-09-12 19:17:16 INF Relay listener shutting down (id=dynamic+https://relays.syncthing.net/endpoint log.pkg=connections) 2026-09-12 19:17:16 WRN Service failed (error="Get \"https://relays.syncthing.net/endpoint\": dial tcp: lookup relays.syncthing.net on 8.8.8.8:53: dial udp 8.8.8.8:53: connect: network is unreachable" supervisor=listenerSupervisor@dynamic+https://relays.syncthing.net/endpoint service=dynamic+https://relays.syncthing.net/endpoint log.pkg=connections) 2026-09-12 19:18:30 INF Relay listener starting (id=dynamic+https://relays.syncthing.net/endpoint log.pkg=connections) 2026-09-12 19:18:30 INF Relay listener shutting down (id=dynamic+https://relays.syncthing.net/endpoint log.pkg=connections) 2026-09-12 19:18:30 WRN Service failed (error="Get \"https://relays.syncthing.net/endpoint\": dial tcp: lookup relays.syncthing.net on 8.8.8.8:53: dial udp 8.8.8.8:53: connect: network is unreachable" supervisor=listenerSupervisor@dynamic+https://relays.syncthing.net/endpoint service=dynamic+https://relays.syncthing.net/endpoint log.pkg=connections) 2026-09-12 19:18:30 INF Relay listener starting (id=dynamic+https://relays.syncthing.net/endpoint log.pkg=connections) 2026-09-12 19:18:30 INF Relay listener shutting down (id=dynamic+https://relays.syncthing.net/endpoint log.pkg=connections) 2026-09-12 19:18:30 WRN Service failed (error="Get \"https://relays.syncthing.net/endpoint\": dial tcp: lookup relays.syncthing.net on 8.8.8.8:53: dial udp 8.8.8.8:53: connect: network is unreachable" supervisor=listenerSupervisor@dynamic+https://relays.syncthing.net/endpoint service=dynamic+https://relays.syncthing.net/endpoint log.pkg=connections) 2026-09-12 19:18:30 INF Relay listener starting (id=dynamic+https://relays.syncthing.net/endpoint log.pkg=connections) 2026-09-12 19:18:30 INF Relay listener shutting down (id=dynamic+https://relays.syncthing.net/endpoint log.pkg=connections) 2026-09-12 19:18:30 WRN Service failed (error="Get \"https://relays.syncthing.net/endpoint\": dial tcp: lookup relays.syncthing.net on 8.8.8.8:53: dial udp 8.8.8.8:53: connect: network is unreachable" supervisor=listenerSupervisor@dynamic+https://relays.syncthing.net/endpoint service=dynamic+https://relays.syncthing.net/endpoint log.pkg=connections) After that, I followed your suggestions. Followed the IPs given through Tailnet while connected to the app. Could reach Immich,, my router, and nothing else. No idea what I'm doing wrong.
Chris wrote:
Hi 1ye — now I see the actual issue. The log is telling us that syncthing (and likely other containers) can't reach external network services at all. That "network is unreachable" when trying to reach 8.8.8.8 means the container network itself is disconnected, not a Tailscale problem. This is almost always either: 1. The VPN container (gluetun) is down or misconfigured, so it's not providing the tunnel the media apps need 2. Docker's container-to-host networking is broken 3. A firewall or routing issue on your host machine Let's find out which one. Please run these two commands and paste the output: 1. sudo sparkbox doctor (This will show the health of every container and flag any networking issues) 2. sudo docker ps --filter name=gluetun --format "table {{.Names}}\t{{.Status}}" (This shows whether the VPN container is actually running) Paste both outputs and we'll know exactly what to fix next.
1ye wrote:
This was pulled from sudo sparkbox doctor: / | | | | ) \ \| ' \ / | '| |/ / \ / \ \/ / ) | |) | (| | | | <| |) | () < |/| ./ \,|| ||\\/ \//\\ || SparkBox v1.6.682 - Self-Hosted Privacy Stack Created by Tom Spark | youtube.com/@TomSparkReviews Network profile: private SparkBox Doctor Running diagnostics... [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: 29.7.2 (engine) [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] [ERROR] sb-portainer IS listening on 127.0.0.1:9000, but the connection timed out instead of connecting — that's Windows/WSL2's 'mirrored' networking mode blackholing loopback traffic, not a Portainer problem The tell: a genuinely closed port refuses instantly; this one hangs for several seconds because a Hyper-V firewall rule (or the mirrored-loopback bug itself) is silently dropping the connection instead of rejecting it. This blocks every app on this box the same way, not just Portainer — the dashboard and qBittorrent too. Fix from an administrator PowerShell: Set-NetFirewallHyperVVMSetting -Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -DefaultInboundAction Allow wsl --shutdown Still blocked? Do NOT switch back to NAT mode — that only moves the fault: NAT hands the box a private 172.x address that no phone, TV or console can reach, and this same doctor will then flag it and point you back to mirrored, which is the loop you are stuck in. Fix the firewall rule above, or use the NAT + port-forward walkthrough below instead of flipping modes. Full walkthrough: https://tomsparkbox.com/guides/run-sparkbox-on-windows-wsl [WARN] Windows Firewall may have your network on its 'Public' profile, which blocks every incoming connection to this box Windows flips a network to Public silently (a new router, a Windows update, a changed port), and while it is Public the firewall drops inbound traffic before it reaches WSL — so app addresses time out from the PC itself no matter whether WSL is mirrored or NAT, and even after the Hyper-V rule is set. Check from an administrator PowerShell: Get-NetConnectionProfile | Select-Object Name, NetworkCategory If your home network says 'Public', flip it back to Private: Set-NetConnectionProfile -NetworkCategory Private Then reload the app address on the PC. [VPN Tunnel] [OK] Gluetun tunnel is healthy [Hardware Transcoding] [INFO] /dev/dri not found -- Intel/AMD hardware transcoding not available [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: 836GB [System Resources] [INFO] Total RAM: 7830MB [INFO] Available RAM: 3836MB [OK] 7830MB RAM is enough for 11 enabled apps (~5632MB estimated) [OK] No out-of-memory kills in the last 24h [INFO] Free disk at /opt/sparkbox (the SparkBox install disk): 836GB [Container Health] [ERROR] sb-seerr is running, but its health check is failing (Docker reports 'unhealthy') The app has started but is not answering properly, so it will look broken or half-working. Last few log lines: │ 2026-09-12T12:12:02.814Z [debug][Download Tracker]: Found 10 item(s) in progress on Sonarr server: Sonarr │ 2026-09-12T12:13:02.569Z [debug][Jobs]: Starting scheduled job: Download Sync │ 2026-09-12T12:13:02.782Z [debug][Download Tracker]: Found 10 item(s) in progress on Sonarr server: Sonarr Try: sudo sparkbox up (and 'sparkbox logs <name' to see why a container is unhappy) [OK] Zombie processes: 26 [OK] Load average is fine for 4 core(s) [WARN] sb-npm is unhealthy but ports and data folder look OK — check: sparkbox logs npm [Tailscale Inbound Path] [OK] Tailscale's inbound path reaches the dashboard (127.0.0.1:8443 from inside sb-tailscale) — phones on your tailnet can get through [Tailscale Reachability] [OK] Dashboard reachable on the LAN IP (192.168.8.177:8443) — no Tailscale route shadow [Windows (WSL) Networking] [OK] Running on Windows (WSL) with 192.168.8.177 — a real home-network address, so other devices can reach this box [WARN] Windows Firewall may have your network on its 'Public' profile, which blocks every incoming connection to this box Windows flips a network to Public silently (a new router, a Windows update, a changed port), and while it is Public the firewall drops inbound traffic before it reaches WSL — so app addresses time out from the PC itself no matter whether WSL is mirrored or NAT, and even after the Hyper-V rule is set. Check from an administrator PowerShell: Get-NetConnectionProfile | Select-Object Name, NetworkCategory If your home network says 'Public', flip it back to Private: Set-NetConnectionProfile -NetworkCategory Private Then reload the app address on the PC. [OK] Start-with-Windows task is registered and running — SparkBox survives closed windows and reboots [Network] [OK] Saved address matches this box [Internet exposure] [OK] Admin surfaces are open to your local network only (this host's internet route uses a private address: 192.168.8.177): portainer (port 9000), dashboard (port 8443) ============================================ 3 issue(s) found. Review warnings above and fix as needed. ============================================ From sudo docker ps --filter name=gluetun --format "table {{.Names}}\t{{.Status}}" the following came back:NAMES STATUS sb-gluetun Up 2 hours (healthy)
Chris wrote:
Hi 1ye — now I see exactly what's happening. The doctor output shows your dashboard and Tailscale ARE working fine, but Windows Firewall is silently blocking the connection before it reaches WSL. Here's the fix: From an administrator PowerShell on your PC: 1. First, check your network profile: Get-NetConnectionProfile | Select-Object Name, NetworkCategory If your home network shows 'Public' instead of 'Private', that's the culprit — it blocks ALL inbound traffic to WSL. 2. If it's Public, flip it back to Private: Set-NetConnectionProfile -NetworkCategory Private 3. Then fix the Hyper-V firewall rule (this unblocks the loopback issue you're seeing with Portainer and the dashboard): Set-NetFirewallHyperVVMSetting -Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -DefaultInboundAction Allow 4. Finally, restart WSL: wsl --shutdown Once you do that, reload your dashboard address from the PC and it should come through. Syncthing will also reconnect once the network is back — the 'network unreachable' errors in its logs will clear automatically. — Chris
Chris wrote:
Hi 1ye — just checking in. Did those PowerShell commands work, or are you still running into the network issue? No rush if you're working through it offline, but let us know how it goes or if you hit a snag with any of the steps.