Hi all, just did a new install for SparkBox and when I try to get into the GUI all I get is a white screen. Is there a fix to this? Thanks!
22 replies
tomspark wrote:
Hey notrike — couple of fast diagnostics that pin this down quickly. Open F12 → Console on the white-screen tab and paste any red errors. On the SparkBox host, run sudo /opt/sparkbox/sparkbox doctor and curl -k https://localhost:8443 | head -c 500. If doctor's all green and curl returns real dashboard HTML, it's browser-side (most common: stale service worker from a prior install — DevTools → Application → Service Workers → Unregister, then hard reload). If doctor flags anything or curl returns blank, that's our bug and the output points at where.
notrike wrote:
There seems to be no erros when I hit F12. I am SSHing into the local host. I ran the Doctor command and I got this one Error: [Container Egress] [ERROR] Containers CANNOT reach webhook.tomsparkbox.com — license activation will fail. Most common cause: UFW DEFAULTFORWARDPOLICY is DROP. Check + fix: grep DEFAULTFORWARDPOLICY /etc/default/ufw sudo sed -i -E 's|^[[:space:]]DEFAULTFORWARDPOLICY[[:space:]]=.|DEFAULTFORWARDPOLICY="ACCEPT"|' /etc/default/ufw sudo ufw reload sudo docker restart sb-dashboard Re-run 'sparkbox doctor' to verify. and I get this when I run the Curl command: curl -k https://localhost:8443 | head -c 500 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 0 curl: (35) TLS connect error: error:0A00010B:SSL routines::wrong version number
tomspark wrote:
Sorry — my curl line had the wrong port. 8443 is the dashboard's internal HTTP port (not user-facing); your real GUI runs through NPM on HTTPSPORT (default 443 on a non-NAS box). That TLS error is just curl trying TLS on an HTTP port, unrelated to the white screen. Two real diagnostics: 1) sudo docker ps | grep -E 'sb-dashboard|sb-npm' — both should report Up (healthy). 2) curl -k https://localhost | head -c 500 (no port = 443) — should return real dashboard HTML. Also: what's the exact URL you have bookmarked when you see the white screen? The egress ERROR is cosmetic — SparkBox is free, license activation is optional, every bundled app runs regardless. Doctor's wording on it is misleading; we just shipped v1.6.70 to soften it.
tomspark wrote:
Quick recap since I accidentally deleted your last reply during a thread cleanup — you had: both containers Up (healthy), and curl https://localhost returned tlsv1 unrecognized name, and you're using http://192.168.1.115:8443 as your dashboard URL. http://192.168.1.115:8443 is actually a fine URL — that's the dashboard's direct HTTP port, no TLS needed there. White screen + zero F12 errors means the SPA shell loaded but won't render. Three diagnostics: 1) F12 → Network tab → reload. Any request return non-200? Especially watch /api/setup/status, /api/auth/status, /api/health/deep. 2) curl -ki http://192.168.1.115:8443 | head -c 800 from the host — should show real HTML with <script src="/js/app.js". Paste it. 3) cat /opt/sparkbox/VERSION — what version are you on? The 'unrecognized name' on https://localhost is just NPM rejecting SNI for the literal string 'localhost'. Try https://192.168.1.115 (your LAN IP, port 443, accept the cert warning) — that's the proper URL once NPM's serving.
notrike wrote:
So I have 2 errors in the F12 Are these what you are talking about? I did the Curl command and here is what came out: curl -ki http://192.168.1.115:8443 | head -c 800 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 0HTTP/1.1 200 OK Content-Security-Policy: default-src 'self';script-src 'self';style-src 'self' 'unsafe-inline';font-src 'self';img-src 'self' data:;connect-src 'self' ws: wss:;form-action 'self';base-uri 'self';frame-ancestors 'self';object-src 'none' Cross-Origin-Opener-Policy: same-origin Cross-Origin-Resource-Policy: same-origin Origin-Agent-Cluster: ?1 Referrer-Policy: no-referrer X-Content-Type-Options: nosniff X-DNS-Prefetch-Control: off X-Download-Options: noopen X-Frame-Options: SAMEORIGIN X-Permitted-Cross-Domain-Policies: none X-XSS-Protection: 0 Set-Cookie: csrf=e23fd649ad98e931cfe9c6766104a62cd80eca67df51e77c379e31a851d51a93; Path=/; SameSite=Lax Set-Cookie: connect.sid=s%3Aa2raLSQ-ApAAFEW4QvXhtVBnL7V5ficT.W3frtpA6ANO3IZivrL2wfe%2BrnQkckFTtioIJlfpeXP8; Path=/; Exp curl: (23) Failure writing output to destination, passed 16384 returned 5712 I am on version 1.6.68
notrike wrote:
Sorry Images didnt work
tomspark wrote:
Got it — that pinned it. NSERRORNETPARTIALTRANSFER on GET / and GET /favicon.ico (200 OK, 0 bytes transferred) is the smoking gun. Server starts the response, then drops the connection mid-stream — index.html arrives truncated and the SPA never mounts. Hence the white screen with zero JS errors. This is our bug. v1.6.63 fixed the same chunked-encoding race for /js/ and /css/ paths but the bypass list missed / (the index.html route) and /favicon.ico. Just shipped v1.6.71 to fix it for real — flipped the filter from a denylist to an allowlist so only /api/ gets compression. Static HTML/images skip it entirely. Update via: sudo /opt/sparkbox/sparkbox update Or if update is broken (since dashboard is white-screened), reinstall over top: curl -fsSL https://get.tomsparkbox.com/install.sh | sudo bash It's idempotent on existing installs. Hard-refresh the browser after (Ctrl+Shift+R) to bust any cache. Should load clean.
notrike wrote:
Ive ran both ways to update and then check with cat /opt/sparkbox/VERSION and its saying im still on 1.6.68 and I am still having the exact same problem
tomspark wrote:
Found why — turns out our release pipeline didn't actually publish v1.6.71 yet. get.tomsparkbox.com/releases/latest/version.txt still says 1.6.68, so install.sh is correctly fetching what's published — there's just nothing newer published yet. Fixing that pipeline now. In the meantime, 30-second hotfix on your box that applies the same patch directly: sudo nano /opt/sparkbox/dashboard/server.js Find the app.use(compression({ block (search for compression(, it's around line 295). Replace the entire filter: (req, res) = { ... } function body with this: filter: (req, res) = { const p = req.path || ''; if (!p.startsWith('/api/')) return false; return compression.filter(req, res); } Save (Ctrl+O, Enter, Ctrl+X), then: sudo docker restart sb-dashboard Wait ~10 seconds, hard-refresh the browser (Ctrl+Shift+R). White screen should be gone. Sorry for the runaround — the bug is real but the release plumbing tripped on top of it.
tomspark wrote:
Update: just published v1.6.71 to get.tomsparkbox.com — curl -sSL https://get.tomsparkbox.com/releases/latest/version.txt now returns 1.6.71 instead of 1.6.68. So either path works: If you already applied the manual hotfix, you're good — same code change. If not, sudo /opt/sparkbox/sparkbox update should now actually pull the new build.
notrike wrote:
I think I accidentally messed up the Nano editing it, is there a way to reset it? Cause now I am getting a loading page error
tomspark wrote:
No problem — sudo /opt/sparkbox/sparkbox update will overwrite server.js with the v1.6.72 official copy and undo whatever the nano edit broke. If update itself is stuck (dashboard in a weird state), the install one-liner reinstalls cleanly: curl -fsSL https://get.tomsparkbox.com/install.sh | sudo bash It's idempotent — won't touch your .env, won't touch your data dir. Either path resets the dashboard to a clean build. After that, hard-refresh the browser (Ctrl+Shift+R).
notrike wrote:
That did it! Thank you so much!
tomspark wrote:
Right on — glad it's working. Your report is what pinned the white-screen bug (v1.6.71) — thanks for sticking with the diagnostic flow.
notrike wrote:
I am coming across another error now where it says "Another first-run claim is in progress. Retry in a few seconds." when I am trying to claim it no matter how long I wait. 😅
tomspark wrote:
That's a stale claim lock left over from your earlier broken-dashboard attempt — the lock file at /opt/sparkbox/state/operation.lock is held in memory until the dashboard process restarts. Quickest fix: sudo docker restart sb-dashboard Wait ~10 seconds for it to come back up, then refresh the dashboard page and try the bootstrap-token claim again. If it still complains after the restart, also clear the lock file directly: sudo rm -f /opt/sparkbox/state/operation.lock sudo docker restart sb-dashboard
notrike wrote:
I have tried both and neither of those worked sadly.
tomspark wrote:
Let's figure out whether it's the dashboard or your browser. From the host: sudo docker logs sb-dashboard --tail 10 sudo ls -la /opt/sparkbox/state/operation.lock 2&1 If the lock file is gone AND the logs look clean, it's stale browser state — hard-refresh the dashboard tab (Ctrl+Shift+R) AND DevTools → Application → Service Workers → Unregister, then retry. If the lock file is still there, recreate the container instead of just restart: sudo docker rm -f sb-dashboard sudo /opt/sparkbox/sparkbox up Recreate fully tears down state in ways restart sometimes doesn't. Paste the docker logs output either way.
notrike wrote:
Here are the docker logs: sudo ls -la /opt/sparkbox/state/operation.lock 2&1 at async Object.writeFile (node:internal/fs/promises:1219:14) Error: ENOENT: no such file or directory, open '/app/state/sessions/jMyPnlpn3OUePF2NrtuyUd6wJMl7Tcly.json.1.1778358895136.tmp' at async open (node:internal/fs/promises:637:25) at async Object.writeFile (node:internal/fs/promises:1219:14) Error: ENOENT: no such file or directory, open '/app/state/sessions/1uHDwtFGwmp6uv6PvEWRo-rFxtgYONY.json.1.1778358919254.tmp' at async open (node:internal/fs/promises:637:25) at async Object.writeFile (node:internal/fs/promises:1219:14) Error: ENOENT: no such file or directory, open '/app/state/sessions/zGoIXTWJgcA3vmQGQrXJzUOZ97tDtTqY.json.1.1778358925347.tmp' at async open (node:internal/fs/promises:637:25) at async Object.writeFile (node:internal/fs/promises:1219:14) ls: cannot access '/opt/sparkbox/state/operation.lock': No such file or directory I guess im missing some files?
tomspark wrote:
Yep — that's the smoking gun. Dashboard's session writer is failing on /app/state/sessions/ (every ENOENT line) because that directory doesn't exist. That cascades into the lock issue: each claim attempt creates a session, the session write fails mid-response, the lock release path gets short-circuited. Fix: sudo mkdir -p /opt/sparkbox/state/sessions sudo chown -R 1000:1000 /opt/sparkbox/state/sessions sudo docker restart sb-dashboard That creates the dir owned by PUID 1000 (what your containers run as). Wait ~10s, hard-refresh, and the bootstrap claim should go through. This is our bug — install.sh and sparkbox up should be ensuring this dir exists before starting the dashboard. Patching it now (v1.6.73).
notrike wrote:
Sadly that did nothing, still the same issue
tomspark wrote:
That tells me sb-dashboard is still running the OLD image — docker restart reuses the cached image, so any pre-v1.6.71 build still hits the session + compression bugs even with v1.6.73 code on disk. Force a full rebuild + restage: curl -fsSL https://get.tomsparkbox.com/install.sh | sudo bash Idempotent — won't touch your .env or data dir, but it WILL re-pull v1.6.73 source, rebuild the dashboard image fresh, and ensure every state dir exists. After that, hard-refresh the browser and the bootstrap claim should land cleanly. If it STILL doesn't, paste sudo docker exec sb-dashboard cat /app/VERSION and sudo docker logs sb-dashboard --tail 20 so I can see what's actually running inside the container vs on disk.