Hi Tom, Any progress on the TomAI issue or a possible workaround? I've got far too used to the AI 🙄 The below was at 30mins past the UTC rollover - ish. Cheers, Paul I hit a problem reaching the AI service mid-task: You've reached today's Tom AI usage budget for this SparkBox. It resets at midnight UTC (00:00) — try again after the reset.. Try again in a moment. trying to export configuration for migration to new server but keeps failing I've actually hit today's Tom AI usage cap on this box — that error isn't me dodging you, it's a hard budget limit that resets at midnight UTC. I can't run diagnostics again until then. Once it resets, come back and I'll dig into the export failure properly — for now, if it's urgent, post the details (exact error message from the export attempt) on demox.world/d/sparkbox and Tom or someone else can take a look.
12 replies
paulrturnbull wrote:
Forget that last message. TomAI back Cheers, Paul
tomspark wrote:
No worries, glad it sorted itself — but your timestamps are actually really useful. The limit is supposed to clear right at midnight UTC, and yours stayed stuck for a good half hour past that before letting you back in. That's a known glitch we're already tracking (another user hit it last week), so thanks for noting the times. No workaround yet beyond waiting it out, but it's on the fix list. And if that config export to the new server is still failing, post the exact error here and I'll help you with the move directly — no AI needed.
paulrturnbull wrote:
Hi Tom, Yep, lost TomAI again. The below is what we were working on. Trying to use the export config button to migrate to another server. I'll continue the manual way that was listed in the chat. Cheers, Paul Trying to migrate to a new server but the export button isn't working for me Everything's healthy now — dashboard just restarted fresh (47 seconds up), which lines up with what I saw last time. Good news on that front. But nothing in this log actually shows an export/backup attempt — the dashboard just restarted (state file perms migration is a one-time startup thing, unrelated to backups). So the export button click either isn't reaching the backend at all, or it failed before logging anything, or you haven't tried it since the restart. A couple of things I want to nail down before guessing: What exactly happens when you click Export/Backup? Does the button spin forever, show an error toast, or just do nothing? Also worth knowing — your media drive is at 89% full per the alert just now. If export is trying to do a full (not config-only) backup, that's likely to fail the same way your scheduled one did (not enough free space) — same root cause as before, just triggered manually this time. Try the export now that the dashboard's freshly restarted, and if it fails again, tell me the exact error text it shows — that'll tell me if it's the same disk-space wall or something else. Media drive should be less now that I've emptied the recycle and configured a scheduled clean up. The server Migration | Export Configuration under Tools presents a password prompt then nothing happens Still nothing logged for an export attempt — no request even hit the backend when you tried it. So this isn't a backend crash, it's likely failing client-side in the browser, before any request goes out. That tracks with what you're describing: password prompt appears (that's a client-side modal), then nothing — meaning whatever happens after you submit that password (encrypting the archive, triggering the download) isn't firing. A few things to check/try, in order of likely culprit: Browser console errors — open dev tools (F12) → Console tab, submit the password again, see if a JS error throws right after you hit submit. That'll tell us exactly where it's dying client-side. Ad blocker / extension blocking the download — some blockers kill blob/file downloads silently. Try in an incognito window with extensions off. Pop-up/download blocked by the browser itself — check the address bar for a blocked-download icon. Media drive at 89% — even though you're cleaning it up, if this export tries to bundle more than config (some export flows still check total available space before writing the archive), it could silently abort. Worth confirming your cleanup actually freed space yet. Can you open the console and try it again, then paste what shows up? That's the fastest way to actually find where it's failing rather than guessing further. v2/:1 The Cross-Origin-Opener-Policy header has been ignored, because the URL's origin was untrustworthy. It was defined either in the final response or a redirect. Please deliver the response using the HTTPS protocol. You can also use the 'localhost' origin instead. See https://www.w3.org/TR/powerful-features/potentially-trustworthy-origin and https://html.spec.whatwg.org/the-cross-origin-opener-policy-header. v2/:1 The Cross-Origin-Opener-Policy header has been ignored, because the URL's origin was untrustworthy. It was defined either in the final response or a redirect. Please deliver the response using the HTTPS protocol. You can also use the 'localhost' origin instead. See https://www.w3.org/TR/powerful-features/potentially-trustworthy-origin and https://html.spec.whatwg.org/the-cross-origin-opener-policy-header. v2/:783 The page requested an origin-keyed agent cluster using the Origin-Agent-Cluster header, but could not be origin-keyed since the origin 'http://192.168.86.56:8443' had previously been placed in a site-keyed agent cluster. Update your headers to uniformly request origin-keying for all pages on the origin. api/migrate/export:1 Failed to load resource: net::ERREMPTYRESPONSE api/migrate/export:1 Failed to load resource: net::ERRCONNECTIONREFUSED api/migrate/export:1 Failed to load resource: net::ERRCONNECTIONREFUSED api/migrate/export:1 Failed to load resource: net::ERRCONNECTIONREFUSED api/migrate/export:1 Failed to load resource: net::ERREMPTYRESPONSE 🔧 working on your SparkBox… 🔧 working on your SparkBox… Everything's healthy right now — dashboard's been up 2 minutes, all containers fine. Media drive's down to 87% (was 89%), so your cleanup's working, just slowly. But here's the thing: dashboard just restarted again (2 minutes ago). That's the actual smoking gun. ERRCONNECTIONREFUSED and ERREMPTYRESPONSE on api/migrate/export mean the dashboard container was mid-restart or crashing exactly when your export request landed — the browser had nothing to talk to. Nothing in the log shows why it restarted — no crash trace, no OOM kill, just a clean startup sequence (the perms migration lines are routine, not an error). That either means: Something external restarted it (you, a script, an update timer) Or it crashed hard enough that the crash reason isn't in this log window Try the export again now that it's stable and been up a couple minutes. If it fails the same way, that tells us the dashboard is actively crashing during the export itself (likely from memory pressure building the archive) rather than just bad timing — and at that point restarting the dashboard module cleanly is the next move. Want me to restart the dashboard module now to get you a clean baseline before you try again, or do you want to just retry as-is first? ↗ Didn’t fully fix it? Share to demox so Tom can ship an update v2/:1 The Cross-Origin-Opener-Policy header has been ignored, because the URL's origin was untrustworthy. It was defined either in the final response or a redirect. Please deliver the response using the HTTPS protocol. You can also use the 'localhost' origin instead. See https://www.w3.org/TR/powerful-features/potentially-trustworthy-origin and https://html.spec.whatwg.org/the-cross-origin-opener-policy-header. v2/:1 The Cross-Origin-Opener-Policy header has been ignored, because the URL's origin was untrustworthy. It was defined either in the final response or a redirect. Please deliver the response using the HTTPS protocol. You can also use the 'localhost' origin instead. See https://www.w3.org/TR/powerful-features/potentially-trustworthy-origin and https://html.spec.whatwg.org/the-cross-origin-opener-policy-header. v2/:783 The page requested an origin-keyed agent cluster using the Origin-Agent-Cluster header, but could not be origin-keyed since the origin 'http://192.168.86.56:8443' had previously been placed in a site-keyed agent cluster. Update your headers to uniformly request origin-keying for all pages on the origin. api/migrate/export:1 Failed to load resource: net::ERREMPTYRESPONSE api/migrate/export:1 Failed to load resource: net::ERRCONNECTIONREFUSED api/migrate/export:1 Failed to load resource: net::ERRCONNECTIONREFUSED api/migrate/export:1 Failed to load resource: net::ERRCONNECTIONREFUSED api/migrate/export:1 Failed to load resource: net::ERREMPTYRESPONSE app.js:1920 GET http://192.168.86.56:8443/api/migrate/export net::ERRCONNECTIONREFUSED doFetch @ app.js:1920 (anonymous) @ app.js:1922 🔧 working on your SparkBox… Yeah, there it is — sb-dashboard is only "Up About a minute." It's restarted again since your last message. That's now three times in a row while you've been trying this export. ERRCONNECTIONREFUSED on api/migrate/export means your browser hit the dashboard at the exact moment the container was down/restarting — not a bug in the export logic itself, the whole dashboard is bouncing. The COOP/Origin-Agent-Cluster warnings are just noise — cosmetic browser warnings because you're on plain HTTP (192.168.86.56:8443) instead of HTTPS, unrelated to your actual problem. Something is knocking the dashboard container over repeatedly. Rather than have you keep clicking Export into a moving target, let's get it stable first. Want me to restart the dashboard module now and then we watch if it holds steady before you retry the export? ↗ Didn’t fully fix it? Share to demox so Tom can ship an update yep Right — dashboard's core, so this tool won't touch it (would take down the very UI you're using to talk to me). That one needs a manual restart from the host: sparkbox restart dashboard or if that alias isn't available: sparkbox up dashboard (force-recreates it). Run that from a terminal on the box, wait ~30 seconds, then try the export again. If it keeps restarting on its own after that (not because of the command, but repeatedly crashing again a minute or two later), that's not something a restart will actually fix — it means something's crash-looping it, and at that point I'd say get this in front of Tom directly via the demox forum with what you've seen here, since a dashboard that won't stay up is squarely his code, not a module issue. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update [INFO] Restarting module: dashboard (recreating to pick up .env changes) WARN[0000] Found orphan containers ([sb-vaultwarden sb-tailscale sb-pihole sb-navidrome sb-qbittorrent sb-sabnzbd sb-radarr sb-lidarr sb-prowlarr sb-sonarr sb-byparr sb-deunhealth sb-gluetun sb-bazarr sb-seerr sb-jellyfin-media sb-notifiarr sb-open-webui sb-ollama sb-filebrowser sb-npm sb-portainer sb-homepage sb-actual sb-duplicati sb-audiobookshelf]) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up. [+] up 1/1 ✔ Container sb-dashboard Started 11.5s [OK] Restart complete. pturnbull@paul-T5610:~$ 🔧 working on your SparkBox… Dashboard's been up 16 seconds
paulrturnbull wrote:
Chat has been truncated. Should I keep pasting in or can I send a zip file of the text? Here's the end: Yep — confirmed. sb-dashboard is only 43 seconds old, it just cycled again. Everything else looks healthy, so this is isolated to the dashboard container specifically bouncing on a short cycle — not a wider stack issue. Given it's restarting itself with no error trace in its own log, on a clean ~3 minute cadence, independent of what you're clicking — this is squarely dashboard-core behavior, which is Tom's code, not a module/config thing I can fix with the tools I've got. Two things to do: Check if something's actually scripted this. Any chance you (or a script/cron job) have something set up that periodically runs sparkbox restart dashboard or docker restart sb-dashboard? Worth ruling out on your end before we call it a bug. If nothing on your side is doing it — this is worth putting in front of Tom directly. Click Share to demox below with this thread; the repeating clean-restart-with-no-crash-log pattern plus the export failing mid-request is exactly the kind of thing that needs a real fix, not a workaround. In the meantime, for the actual migration: since the dashboard won't hold still long enough to finish an export, you could sidestep it entirely and pull the config straight off the host instead — a plain tar of /opt/sparkbox/.env and /opt/sparkbox/modules//config (or /opt/sparkbox/state for the app passwords) gets you the same data without needing the export button at all. Want me to spell out that manual tar command? ↗ Didn’t fully fix it? Share to demox so Tom can ship an update yes please Here's the manual path — same data the export button would give you, just done straight from the shell so the dashboard bouncing doesn't matter. cd /opt/sparkbox sudo tar -czvf ~/sparkbox-config-manual-$(date +%Y%m%d).tar.gz \ .env \ modules//docker-compose.yml \ modules//docker-compose.hw.yml \ state Notes on what that grabs and why: .env — all your config, VPN creds, PUID/PGID, ports, MEDIAROOT, everything modules//docker-compose.yml (+ .hw.yml where present) — your compose overrides, in case you've hand-edited any state/ — this is the big one: app admin passwords (qBittorrent, Radarr, Sonarr, Portainer, Vaultwarden, Pi-hole, etc.), license.json, wizard.json, install-meta.conf — basically everything the dashboard itself tracks That .hw.yml glob will just silently skip if you don't have hardware transcoding set up — no error, don't worry about it. Copy the resulting .tar.gz off the box (scp, USB, whatever) to bring to the new server. On the new box, after a fresh SparkBox install to the same install root, you'd stop the stack, extract that archive back into /opt/sparkbox (same relative paths), then sparkbox up to bring it back with your existing config and passwords intact. One thing this does not include: your actual media files, Jellyfin/Immich libraries, or app databases beyond what's in state/ — those live under your Media root (/opt/sparkbox/data/media) and need their own copy (rsync/robocopy/whatever, since they're likely large) separately from this config tarball. If the dashboard keeps bouncing and you want to rule out something scripted before escalating, worth running crontab -l and checking systemctl list-timers while you're at it — but otherwise, this gets you a safe config backup independent of whatever's happening with the export button. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update pturnbull@paul-T5610:~$ systemctl list-timers NEXT LEFT LAST PASSED UNIT ACTIVATES Thu 2026-07-09 12:02:17 AEST 19min Thu 2026-07-09 11:06:22 AEST 36min ago fwupd-refresh.timer fwupd-refresh.service Thu 2026-07-09 12:04:56 AEST 21min Wed 2026-07-08 21:04:33 AEST - apt-daily.timer apt-daily.service Thu 2026-07-09 12:31:53 AEST 48min Thu 2026-07-09 11:31:38 AEST 11min ago anacron.timer anacron.service Thu 2026-07-09 23:07:49 AEST 11h Thu 2026-07-09 11:18:50 AEST 24min ago motd-news.timer motd-news.service Thu 2026-07-09 23:39:58 AEST 11h Wed 2026-07-08 23:39:58 AEST 12h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service Fri 2026-07-10 00:00:00 AEST 12h Thu 2026-07-09 00:00:01 AEST 11h ago dpkg-db-backup.timer dpkg-db-backup.service Fri 2026-07-10 00:00:00 AEST 12h Thu 2026-07-09 00:00:01 AEST 11h ago logrotate.timer logrotate.service Fri 2026-07-10 06:19:02 AEST 18h Thu 2026-07-09 06:27:50 AEST 5h 15min ago apt-daily-upgrade.timer apt-daily-upgrade.service Fri 2026-07-10 10:51:11 AEST 23h Thu 2026-07-09 02:23:18 AEST 9h ago man-db.timer man-db.service Fri 2026-07-10 11:46:07 AEST 24h Thu 2026-07-09 00:08:34 AEST 11h ago plocate-updatedb.timer plocate-updatedb.service Sun 2026-07-12 03:10:45 AEST 2 days Sun 2026-07-05 03:10:55 AEST - e2scruball.timer e2scruball.service Mon 2026-07-13 00:01:18 AEST 3 days Mon 2026-07-06 00:03:05 AEST - fstrim.timer fstrim.service 12 timers listed. Pass --all to see loaded but inactive timers, too. pturnbull@paul-T5610:~$ I hit a problem reaching the AI service mid-task: You've reached today's Tom AI usage budget for this SparkBox. It resets at midnight UTC (00:00) — try again after the reset.. Try again in a moment. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update Pass --all to see loaded but inactive timers, too. pturnbull@paul-T5610:~$ crontab -l no crontab for pturnbull pturnbull@paul-T5610:~$ I hit a problem reaching the AI service mid-task: You've reached today's Tom AI usage budget for this SparkBox. It resets at midnight UTC (00:00) — try again after the reset.. Try again in a moment. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update
tomspark wrote:
No need for a zip or more pasting — that last chunk told me what I needed, and I think I see it. The dashboard runs with a small memory allowance, and the export button tries to gather every config file on the box in one go. With a setup your size that likely blows straight past the allowance, so the system kills the dashboard mid-export and it comes back up with a clean log — which would explain the export dying and the bouncing both. One command to confirm: sudo docker inspect sb-dashboard --format '{{.State.OOMKilled}} restarts={{.RestartCount}}' — if it starts with true, that's our culprit, and it's filed as a bug on my end either way. The manual tar route you were given is the right call for the migration in the meantime.
paulrturnbull wrote:
pturnbull@paul-T5610:/opt/sparkbox$ sudo docker inspect sb-dashboard --format '{{.State.OOMKilled}} restarts={{.RestartCount}}' [sudo] password for pturnbull: false restarts=2 pturnbull@paul-T5610:/opt/sparkbox$
tomspark wrote:
Thanks for running that. Two things about the result: the restart counter reset to zero when you ran the restart command earlier, so 2 means it has still died twice since then — just more slowly while you're not using it. And the false doesn't clear my memory theory: when the dashboard's own engine runs out of its memory allowance, it dies in a way that usually doesn't flip that flag. This command lists each time it died, with a code: sudo docker events --filter container=sb-dashboard --since 12h --until 1s Paste any lines containing die. If they say exitCode=134, that's the memory allowance confirmed; 137 means something outside killed it. Either way it's filed as a bug on my end, and the manual tar route stays the right call for your migration.
paulrturnbull wrote:
All say exitCode=0 pturnbull@paul-T5610:/opt/sparkbox$ sudo docker events --filter container=sb-dashboard --since 12h --until 1s 2026-07-09T15:00:36.658188539+10:00 container execcreate: wget -qO- http://127.0.0.1:8443/api/auth/status f8a1d04066f0689cb5fbc59a1762901b8e1336be147e6872df408d9231a08bf6 (com.docker.compose.config-hash=4d8c87bf9791a5c5d666022ccebb6a175129643d04519bcc9654e6ea2ab2e985, com.docker.compose.container-number=1, com.docker.compose.dependson=, com.docker.compose.image=sha256:b04df6deb141c845bd609aa6a2075d50b07616e9cd17f61ad423c560616a5852, com.docker.compose.oneoff=False, com.docker.compose.project=sparkbox, com.docker.compose.project.configfiles=/opt/sparkbox/modules/dashboard/docker-compose.yml, com.docker.compose.project.environmentfile=/opt/sparkbox/.env, com.docker.compose.project.workingdir=/opt/sparkbox/modules/dashboard, com.docker.compose.replace=sb-dashboard, com.docker.compose.service=sparkbox-dashboard, com.docker.compose.version=5.1.4, execID=26855a615368dd4fe92d5bfb71972af8fd1eacfd73555e05eda71d2ff997a47c, image=sparkbox-sparkbox-dashboard, name=sb-dashboard) 2026-07-09T15:00:36.658318450+10:00 container execstart: wget -qO- http://127.0.0.1:8443/api/auth/status f8a1d04066f0689cb5fbc59a1762901b8e1336be147e6872df408d9231a08bf6 (com.docker.compose.config-hash=4d8c87bf9791a5c5d666022ccebb6a175129643d04519bcc9654e6ea2ab2e985, com.docker.compose.container-number=1, com.docker.compose.dependson=, com.docker.compose.image=sha256:b04df6deb141c845bd609aa6a2075d50b07616e9cd17f61ad423c560616a5852, com.docker.compose.oneoff=False, com.docker.compose.project=sparkbox, com.docker.compose.project.configfiles=/opt/sparkbox/modules/dashboard/docker-compose.yml, com.docker.compose.project.environmentfile=/opt/sparkbox/.env, com.docker.compose.project.workingdir=/opt/sparkbox/modules/dashboard, com.docker.compose.replace=sb-dashboard, com.docker.compose.service=sparkbox-dashboard, com.docker.compose.version=5.1.4, execID=26855a615368dd4fe92d5bfb71972af8fd1eacfd73555e05eda71d2ff997a47c, image=sparkbox-sparkbox-dashboard, name=sb-dashboard) 2026-07-09T15:00:36.847592769+10:00 container execdie f8a1d04066f0689cb5fbc59a1762901b8e1336be147e6872df408d9231a08bf6 (com.docker.compose.config-hash=4d8c87bf9791a5c5d666022ccebb6a175129643d04519bcc9654e6ea2ab2e985, com.docker.compose.container-number=1, com.docker.compose.dependson=, com.docker.compose.image=sha256:b04df6deb141c845bd609aa6a2075d50b07616e9cd17f61ad423c560616a5852, com.docker.compose.oneoff=False, com.docker.compose.project=sparkbox, com.docker.compose.project.configfiles=/opt/sparkbox/modules/dashboard/docker-compose.yml, com.docker.compose.project.environmentfile=/opt/sparkbox/.env, com.docker.compose.project.workingdir=/opt/sparkbox/modules/dashboard, com.docker.compose.replace=sb-dashboard, com.docker.compose.service=sparkbox-dashboard, com.docker.compose.version=5.1.4, execID=26855a615368dd4fe92d5bfb71972af8fd1eacfd73555e05eda71d2ff997a47c, exitCode=0, image=sparkbox-sparkbox-dashboard, name=sb-dashboard) 2026-07-09T15:01:06.850655752+10:00 container execcreate: wget -qO- http://127.0.0.1:8443/api/auth/status f8a1d04066f0689cb5fbc59a1762901b8e1336be147e6872df408d9231a08bf6 (com.docker.compose.config-hash=4d8c87bf9791a5c5d666022ccebb6a175129643d04519bcc9654e6ea2ab2e985, com.docker.compose.container-number=1, com.docker.compose.dependson=, com.docker.compose.image=sha256:b04df6deb141c845bd609aa6a2075d50b07616e9cd17f61ad423c560616a5852, com.docker.compose.oneoff=False, com.docker.compose.project=sparkbox, com.docker.compose.project.configfiles=/opt/sparkbox/modules/dashboard/docker-compose.yml, com.docker.compose.project.environmentfile=/opt/sparkbox/.env, com.docker.compose.project.workingdir=/opt/sparkbox/modules/dashboard, com.docker.compose.replace=sb-dashboard, com.docker.compose.service=sparkbox-dashboard, com.docker.compose.version=5.1.4, execID=3d29ff7109279d6c0076643cd953050bfa7c89953cbf8171a78c7899c7f9f439, image=sparkbox-sparkbox-dashboard, name=sb-dashboard) 2026-07-09T15:01:06.850868987+10:00 container execstart: wget -qO- http://127.0.0.1:8443/api/auth/status f8a1d04066f0689cb5fbc59a1762901b8e1336be147e6872df408d9231a08bf6 (com.docker.compose.config-hash=4d8c87bf9791a5c5d666022ccebb6a175129643d04519bcc9654e6ea2ab2e985, com.docker.compose.container-number=1, com.docker.compose.dependson=, com.docker.compose.image=sha256:b04df6deb141c845bd609aa6a2075d50b07616e9cd17f61ad423c560616a5852, com.docker.compose.oneoff=False, com.docker.compose.project=sparkbox, com.docker.compose.project.configfiles=/opt/sparkbox/modules/dashboard/docker-compose.yml, com.docker.compose.project.environmentfile=/opt/sparkbox/.env, com.docker.compose.project.workingdir=/opt/sparkbox/modules/dashboard, com.docker.compose.replace=sb-dashboard, com.docker.compose.service=sparkbox-dashboard, com.docker.compose.version=5.1.4, execID=3d29ff7109279d6c0076643cd953050bfa7c89953cbf8171a78c7899c7f9f439, image=sparkbox-sparkbox-dashboard, name=sb-dashboard) 2026-07-09T15:01:06.965049961+10:00 container execdie f8a1d04066f0689cb5fbc59a1762901b8e1336be147e6872df408d9231a08bf6 (com.docker.compose.config-hash=4d8c87bf9791a5c5d666022ccebb6a175129643d04519bcc9654e6ea2ab2e985, com.docker.compose.container-number=1, com.docker.compose.dependson=, com.docker.compose.image=sha256:b04df6deb141c845bd609aa6a2075d50b07616e9cd17f61ad423c560616a5852, com.docker.compose.oneoff=False, com.docker.compose.project=sparkbox, com.docker.compose.project.configfiles=/opt/sparkbox/modules/dashboard/docker-compose.yml, com.docker.compose.project.environmentfile=/opt/sparkbox/.env, com.docker.compose.project.workingdir=/opt/sparkbox/modules/dashboard, com.docker.compose.replace=sb-dashboard, com.docker.compose.service=sparkbox-dashboard, com.docker.compose.version=5.1.4, execID=3d29ff7109279d6c0076643cd953050bfa7c89953cbf8171a78c7899c7f9f439, exitCode=0, image=sparkbox-sparkbox-dashboard, name=sb-dashboard) 2026-07-09T15:01:36.967368816+10:00 container execcreate: wget -qO- http://127.0.0.1:8443/api/auth/status f8a1d04066f0689cb5fbc59a1762901b8e1336be147e6872df408d9231a08bf6 (com.docker.compose.config-hash=4d8c87bf9791a5c5d666022ccebb6a175129643d04519bcc9654e6ea2ab2e985, com.docker.compose.container-number=1, com.docker.compose.dependson=, com.docker.compose.image=sha256:b04df6deb141c845bd609aa6a2075d50b07616e9cd17f61ad423c560616a5852, com.docker.compose.oneoff=False, com.docker.compose.project=sparkbox, com.docker.compose.project.configfiles=/opt/sparkbox/modules/dashboard/docker-compose.yml, com.docker.compose.project.environmentfile=/opt/sparkbox/.env, com.docker.compose.project.workingdir=/opt/sparkbox/modules/dashboard, com.docker.compose.replace=sb-dashboard, com.docker.compose.service=sparkbox-dashboard, com.docker.compose.version=5.1.4, execID=771719518e7666b6443afaaa2da3bc388e9f85ce285d5f02c75215bea99c47ba, image=sparkbox-sparkbox-dashboard, name=sb-dashboard) 2026-07-09T15:01:36.967627101+10:00 container execstart: wget -qO- http://127.0.0.1:8443/api/auth/status f8a1d04066f0689cb5fbc59a1762901b8e1336be147e6872df408d9231a08bf6 (com.docker.compose.config-hash=4d8c87bf9791a5c5d666022ccebb6a175129643d04519bcc9654e6ea2ab2e985, com.docker.compose.container-number=1, com.docker.compose.dependson=, com.docker.compose.image=sha256:b04df6deb141c845bd609aa6a2075d50b07616e9cd17f61ad423c560616a5852, com.docker.compose.oneoff=False, com.docker.compose.project=sparkbox, com.docker.compose.project.configfiles=/opt/sparkbox/modules/dashboard/docker-compose.yml, com.docker.compose.project.environmentfile=/opt/sparkbox/.env, com.docker.compose.project.workingdir=/opt/sparkbox/modules/dashboard, com.docker.compose.replace=sb-dashboard, com.docker.compose.service=sparkbox-dashboard, com.docker.compose.version=5.1.4, execID=771719518e7666b6443afaaa2da3bc388e9f85ce285d5f02c75215bea99c47ba, image=sparkbox-sparkbox-dashboard, name=sb-dashboard) 2026-07-09T15:01:37.148376734+10:00 container execdie f8a1d04066f0689cb5fbc59a1762901b8e1336be147e6872df408d9231a08bf6 (com.docker.compose.config-hash=4d8c87bf9791a5c5d666022ccebb6a175129643d04519bcc9654e6ea2ab2e985, com.docker.compose.container-number=1, com.docker.compose.dependson=, com.docker.compose.image=sha256:b04df6deb141c845bd609aa6a2075d50b07616e9cd17f61ad423c560616a5852, com.docker.compose.oneoff=False, com.docker.compose.project=sparkbox, com.docker.compose.project.configfiles=/opt/sparkbox/modules/dashboard/docker-compose.yml, com.docker.compose.project.environmentfile=/opt/sparkbox/.env, com.docker.compose.project.workingdir=/opt/sparkbox/modules/dashboard, com.docker.compose.replace=sb-dashboard, com.docker.compose.service=sparkbox-dashboard, com.docker.compose.version=5.1.4, execID=771719518e7666b6443afaaa2da3bc388e9f85ce285d5f02c75215bea99c47ba, exitCode=0, image=sparkbox-sparkbox-dashboard, name=sb-dashboard) 2026-07-09T15:02:07.150038165+10:00 container execcreate: wget -qO- http://127.0.0.1:8443/api/auth/status f8a1d04066f0689cb5fbc59a1762901b8e1336be147e6872df408d9231a08bf6 (com.docker.compose.config-hash=4d8c87bf9791a5c5d666022ccebb6a175129643d04519bcc9654e6ea2ab2e985, com.docker.compose.container-number=1, com.docker.compose.dependson=, com.docker.compose.image=sha256:b04df6deb141c845bd609aa6a2075d50b07616e9cd17f61ad423c560616a5852, com.docker.compose.oneoff=False, com.docker.compose.project=sparkbox, com.docker.compose.project.configfiles=/opt/sparkbox/modules/dashboard/docker-compose.yml, com.docker.compose.project.environmentfile=/opt/sparkbox/.env, com.docker.compose.project.workingdir=/opt/sparkbox/modules/dashboard, com.docker.compose.replace=sb-dashboard, com.docker.compose.service=sparkbox-dashboard, com.docker.compose.version=5.1.4, execID=24da37b692615842cc28ff3a5f3735c5fbf134ef3451a44b5d58ba32eac71262, image=sparkbox-sparkbox-dashboard, name=sb-dashboard) 2026-07-09T15:02:07.150260340+10:00 container execstart: wget -qO- http://127.0.0.1:8443/api/auth/status f8a1d04066f0689cb5fbc59a176
tomspark wrote:
My fault — that command was a dud on a box your size. Those exitCode=0 lines are just the little alive-check that pokes the dashboard every 30 seconds, and Docker only remembers a few minutes of that chatter with 29 apps running, so the actual crash records had already scrolled away. Better plan: open a spare terminal and run sudo docker events --filter container=sb-dashboard --filter event=die It'll sit there quietly — leave the window open and carry on with the manual migration. The moment the dashboard dies again, one line pops out ending in exitCode=some number. Paste that line here: 134 means the memory allowance, 137 means something killed it from outside, 0 means it shut itself down cleanly. If nothing appears for a day, that's useful too — it means the bouncing has settled while you're not using the export.
paulrturnbull wrote:
Thanks for the help Tom, The migration didn't go as well as I would have liked so I've rolled back to my Dell. i was only doing it for idle power reasons to a spare laptop running Ubuntu server I have but after stopping the new Sparkbox , unpacking the tar and bringing Sparkbox back up, there were too many funny little issues including the creation of a new sparkbox user instead of my pturnbull username and issues with some of the module passwords - mainly Qbittorrent. I ended up factory resetting the laptop and going back to what is currently working for me. I will probably revisit the migration later . Cheers, Paul
tomspark wrote:
Rolling back was the right call, and those funny little issues actually make sense now — the backup we put together grabbed your main settings but skipped each app's own folder. Jellyfin's accounts and qBittorrent's real password live in those folders, so the new box never got them: Jellyfin set itself up fresh with its own 'sparkbox' login, and qBittorrent's password didn't match what the dashboard remembered. Nothing was wrong with the laptop itself. When you revisit, the trick is to shut SparkBox down on both machines and copy the whole modules folder across as well — happy to write out the exact steps whenever you're ready. The export button bug stays filed on my end, and no need to babysit that exit-code window anymore.
paulrturnbull wrote:
Thanks for that Tom, The module copy appears to have done the trick and now running on the laptop rather than the more power hungry Dell tower. Paul