AN update this month has caused the following behaviour. Running sudo sparkbox restart media causes the Dashboard to become unresponsive and I have to run sudo sparkbox restart dashboard
Posted by danmacx2
My question: whilst experiencing the issue I ran the commands. sudo docker inspect -f '{{json .State.Health}}' sb-dashboard sudo docker logs --since 15m sb-dashboard curl -k -I https://127.0.0.1:8443 sudo docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}' {"Status":"healthy","FailingStreak":1,"Log":[{"Start":"2026-09-21T17:40:48.805333328+10:00","End":"2026-09-21T17:40:48.898576997+10:00","ExitCode":0,"Output":"{\"authenticated\":false,\"firstRun\":false,\"claimReady\":false,\"loginReady\":{\"sessionsWritable\":true,\"sessionsError\":null,\"sessionsInMemory\":0,\"recoverable\":true}}"},{"Start":"2026-09-21T17:41:18.900375312+10:00","End":"2026-09-21T17:41:19.001152684+10:00","ExitCode":0,"Output":"{\"authenticated\":false,\"firstRun\":false,\"claimReady\":false,\"loginReady\":{\"sessionsWritable\":true,\"sessionsError\":null,\"sessionsInMemory\":0,\"recoverable\":true}}"},{"Start":"2026-09-21T17:41:49.002163991+10:00","End":"2026-09-21T17:41:49.100782323+10:00","ExitCode":0,"Output":"{\"authenticated\":false,\"firstRun\":false,\"claimReady\":false,\"loginReady\":{\"sessionsWritable\":true,\"sessionsError\":null,\"sessionsInMemory\":0,\"recoverable\":true}}"},{"Start":"2026-09-21T17:42:19.101884648+10:00","End":"2026-09-21T17:42:19.189956197+10:00","ExitCode":0,"Output":"{\"authenticated\":false,\"firstRun\":false,\"claimReady\":false,\"loginReady\":{\"sessionsWritable\":true,\"sessionsError\":null,\"sessionsInMemory\":0,\"recoverable\":true}}"},{"Start":"2026- …(reply truncated — full chat sent to Tom)
1 replies
Chris wrote:
Sorry the box needed a second command to come back — that is not how a media restart should behave, and I want to pin it down rather than guess. Two things your paste already tells us, and one check that decides it. What we can see: while the dashboard looked dead, it was still answering its own health check inside its container every 30 seconds (the healthy / ExitCode 0 lines at 17:40 to 17:42), then missed one (that is the FailingStreak 1). So the dashboard process was alive for most of that window rather than crashed, which narrows it to either the dashboard stalling on something the media recreate leaves behind, or the path between your browser and the container. Recreating the dashboard clears both, which is why sudo sparkbox restart dashboard works — but it is a workaround, not the fix. One correction on the commands you were given: the dashboard speaks plain http on 8443, so curl -k -I https://127.0.0.1:8443 errors out whether the box is fine or not — that line could not tell us anything. Sorry about that; we have corrected what the assistant knows so it does not send the next person down the same path. The one check: next time it happens, before you restart the dashboard, run these from the NAS shell and paste what comes back: - line 1: curl -s -m 5 -o /dev/null -w '%{httpcode}\n' http://127.0.0.1:8443/api/auth/status - line 2: sudo docker port sb-dashboard - line 3: sudo docker logs --since 10m sb-dashboard 2&1 | tail -20 A 200 on line 1 means the dashboard answers on the NAS itself and the problem sits between the NAS and your browser; a timeout on line 1 with line 2 still printing the 8443 mapping means the dashboard itself stalled and the log tail will say on what; line 2 printing nothing means Docker dropped the dashboard's published port during the media recreate. Each of those is a different fix on our side, and with that paste I can ship the right one. Please add sudo sparkbox version so I know which build you were on. — Chris