I recently restructured the storage on my home server — repurposed an old media drive into a dedicated backup drive (/srv/backups, separate physical disk, mounted via fstab with nofail), and pointed my media module at a fresh drive instead. That part went smoothly: had to use sparkbox down media / up media to release the old drive cleanly (raw docker stop kept getting reverted by the watchdog), updated MEDIAROOT, and everything came back healthy. The remaining piece was getting SparkBox's own backups to land on the new backup drive instead of staying on the system disk. That's where I hit a wall. sparkbox backup runs, prints its two INFO lines, and exits cleanly within seconds — but never actually creates a file. Tried it with --dest /srv/backups, tried a symlink from /opt/sparkbox/backups to the new drive, tried the default path with no symlink at all — same result every time. Worked through it with Claude and Tom AI together: Tom AI initially caught a real issue (.env was root-owned instead of UID 1000, causing an EACCES error in the dashboard logs), I fixed that and restarted the dashboard, but the backup command still produced nothing. The diagnostic that nailed it down: comparing docker logs sb-dashboard --tail 20 immediately before and after running sparkbox backup — completely identical output both times, zero new log lines. That points to the CLI command never actually reaching the dashboard's backup API endpoint, rather than a permissions or path problem on my end. The only backup that exists is one created automatically back on June 24th, before any of this restructuring happened. Every manual CLI-triggered attempt since has silently no-op'd. Happy to provide more logs/output if useful — wanted to get this documented while everything was fresh and reproducible.
14 replies
tomspark wrote:
Great diagnostic — the before/after dashboard log comparison is exactly the right test, and identical output both times is a clear signal. The most useful next piece: paste the exact text of those two INFO lines sparkbox backup prints. That'll tell me what the CLI thinks it's doing and help me check whether it's hitting the right internal service. If you can, run it one more time and copy the full output here.
Cthe_Enigma wrote:
Thanks! These are the lines I am seeing: [INFO] Creating FULL backup (config + all module data)... [INFO] This may take a while for large photo/media libraries.
tomspark wrote:
Those two lines are printed right when the command starts — the key question is what happens immediately after. Run this and paste the full output: sparkbox backup; echo "Exit: $?" If it shows "Exit: 0" with nothing else after those two lines, that means the command thinks it succeeded but went silent somewhere between the CLI and the dashboard. That's the exact signal I need to narrow it down.
Cthe_Enigma wrote:
Ah, it shows [Exit: 1], but then nothing after that~ forestprince001@solargrove:~$ sparkbox backup; echo "Exit: $?" [INFO] Creating FULL backup (config + all module data)... [INFO] This may take a while for large photo/media libraries. Exit: 1
tomspark wrote:
Exit: 1 with no message is a real bug — the command failed but didn't say why. That's confirmed and logged. One more thing to try — run this and paste the full output: sparkbox backup 2&1 The only difference is it captures errors that normally disappear silently. Even if it looks identical to before, paste everything you see — that result tells us exactly where it's failing.
Cthe_Enigma wrote:
seems like it may be the same: forestprince001@solargrove:~$ sparkbox backup 2&1 [INFO] Creating FULL backup (config + all module data)... [INFO] This may take a while for large photo/media libraries.
tomspark wrote:
No extra error text in the output is actually a useful signal — it means the failure is happening before the command even tries to say why. Run this one and paste what you get: sparkbox doctor That gives me a health snapshot of your whole setup. If the backup command can't talk to the dashboard service, that'll show up there and point us at the fix.
Cthe_Enigma wrote:
Here is what I got: forestprince001@solargrove:~$ sparkbox doctor / | | | | ) \ \| ' \ / | '| |/ / \ / \ \/ / ) | |) | (| | | | <| |) | () < |/| ./ \,|| ||\\/ \//\\ || SparkBox v1.6.315 - 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): /srv/media-storage [Docker] [OK] Docker daemon is accessible [OK] Docker version: Docker version 29.6.1, build 8900f1d [OK] Docker Compose: 5.2.0 [Docker Socket] [OK] Docker socket exists at /var/run/docker.sock [OK] Docker socket is readable [User IDs] [INFO] Current user: forestprince001 (UID=1000, GID=1000) [OK] PUID=1000 (containers run as UID 1000) [OK] PGID=1000 (containers run as GID 1000) [Container Egress] [OK] Containers can reach webhook.tomsparkbox.com (license server) [Port Conflicts] [WARN] Port 53: in use by non-Docker process LISTEN 0 4096 127.0.0.54:53 0.0.0.0: [OK] Port 80: available [WARN] Port 443: in use by non-Docker process LISTEN 0 4096 0.0.0.0:443 0.0.0.0: [WARN] Port 8080: in use by non-Docker process LISTEN 0 511 0.0.0.0:8080 0.0.0.0: [WARN] Port 8443: in use by non-Docker process LISTEN 0 4096 0.0.0.0:8443 0.0.0.0: [WARN] Port 9000: in use by non-Docker process LISTEN 0 4096 0.0.0.0:9000 0.0.0.0: [OK] Port 9092: available [Portainer Auth] [OK] Portainer admin login verified (HTTP 200) [VPN Tunnel] [OK] Gluetun tunnel is healthy [Hardware Transcoding] [OK] /dev/dri exists -- GPU devices detected total 0 drwxr-xr-x 3 root root 100 Jun 12 03:08 . drwxr-xr-x 21 root root 4540 Jun 28 19:43 .. drwxr-xr-x 2 root root 80 Jun 12 03:08 by-path crw-rw---- 1 root video 226, 1 Jun 12 03:08 card1 crw-rw---- 1 root render 226, 128 Jun 12 03:08 renderD128 [OK] Intel Quick Sync / GPU render device available (renderD128) [WARN] Render device may not be accessible -- check group membership (video/render) [Media Storage] [OK] MEDIAROOT=/srv/media-storage exists [OK] MEDIAROOT is writable [WARN] Your apps (user id 1000) can't READ what's in MEDIAROOT — common with media already on a UGREEN/UGOS NAS. [WARN] Fix (read access without taking ownership): sudo chmod -R o+rX '/srv/media-storage' [WARN] Guide: https://tomsparkbox.com/guides/use-existing-ugreen-media.html [INFO] Free space at MEDIAROOT: 435GB [System Resources] [INFO] Total RAM: 7586MB [INFO] Available RAM: 3670MB [OK] RAM looks sufficient for 7 enabled modules [INFO] Free disk at SBROOT: 354GB [Container Health] [OK] All SparkBox containers are running [Tailscale Reachability] [OK] Dashboard reachable on the LAN IP (10.0.0.221:8443) — no Tailscale route shadow ============================================ 7 issue(s) found. Review warnings above and fix as needed. ============================================ forestprince001@solargrove:~$
tomspark wrote:
Thanks — the doctor output confirms your end is healthy, which means this is confirmed as a bug on our side. Your dashboard is up and all containers are running, but the backup CLI can't reach the API endpoint it needs. One more thing to help pin exactly where the disconnect is: docker port sb-dashboard Paste what comes back — that shows the exact ports the dashboard exposes, and it'll tell me whether the CLI is pointing at the right place.
Cthe_Enigma wrote:
Here you go: forestprince001@solargrove:~$ docker port sb-dashboard 8443/tcp - 0.0.0.0:8443
tomspark wrote:
Thanks — that confirms the dashboard is running and the port mapping is clean. The CLI runs as a shell script with strict error handling: when it hits an internal failure after those two INFO lines, it logs it silently to a file rather than printing anything to the screen. Run this and paste what comes back: tail -20 /opt/sparkbox/state/sparkbox-err-trap.log That's the silent-failure capture log — it records exactly which step triggered the abort. Even if it looks cryptic, paste the whole output and it'll tell us exactly where the backup is dying.
Cthe_Enigma wrote:
forestprince001@solargrove:~$ tail -20 /opt/sparkbox/state/sparkbox-err-trap.log 2026-06-30T01:34:09+00:00 rc=130 line=4804 cmd=docker logs -f --tail 100 "${service}" 2026-06-30T01:40:10+00:00 rc=1 line=4853 cmd=cut -f1 2026-06-30T01:40:10+00:00 rc=1 line=4853 cmd=estsize=$(du -sh "${SBROOT}/data" "${SBROOT}"/modules//data 2 /dev/null | tail -1 | cut -f1) 2026-06-30T01:47:41+00:00 rc=1 line=4853 cmd=cut -f1 2026-06-30T01:47:41+00:00 rc=1 line=4853 cmd=estsize=$(du -sh "${SBROOT}/data" "${SBROOT}"/modules//data 2 /dev/null | tail -1 | cut -f1) 2026-06-30T01:50:00+00:00 rc=1 line=4853 cmd=cut -f1 2026-06-30T01:50:00+00:00 rc=1 line=4853 cmd=estsize=$(du -sh "${SBROOT}/data" "${SBROOT}"/modules//data 2 /dev/null | tail -1 | cut -f1) 2026-06-30T01:57:31+00:00 rc=1 line=4853 cmd=cut -f1 2026-06-30T01:57:31+00:00 rc=1 line=4853 cmd=estsize=$(du -sh "${SBROOT}/data" "${SBROOT}"/modules//data 2 /dev/null | tail -1 | cut -f1) 2026-06-30T02:01:12+00:00 rc=1 line=4853 cmd=cut -f1 2026-06-30T02:01:12+00:00 rc=1 line=4853 cmd=estsize=$(du -sh "${SBROOT}/data" "${SBROOT}"/modules//data 2 /dev/null | tail -1 | cut -f1) 2026-06-30T02:02:54+00:00 rc=1 line=4853 cmd=cut -f1 2026-06-30T02:02:54+00:00 rc=1 line=4853 cmd=estsize=$(du -sh "${SBROOT}/data" "${SBROOT}"/modules//data 2 /dev/null | tail -1 | cut -f1) 2026-06-30T04:20:18+00:00 rc=1 line=4853 cmd=cut -f1 2026-06-30T04:20:18+00:00 rc=1 line=4853 cmd=estsize=$(du -sh "${SBROOT}/data" "${SBROOT}"/modules//data 2 /dev/null | tail -1 | cut -f1) 2026-06-30T04:20:37+00:00 rc=1 line=4853 cmd=cut -f1 2026-06-30T04:20:37+00:00 rc=1 line=4853 cmd=estsize=$(du -sh "${SBROOT}/data" "${SBROOT}"/modules//data 2 /dev/null | tail -1 | cut -f1) 2026-06-30T22:50:57+00:00 rc=1 line=4853 cmd=cut -f1 2026-06-30T22:50:57+00:00 rc=1 line=4853 cmd=estsize=$(du -sh "${SBROOT}/data" "${SBROOT}"/modules//data 2 /dev/null | tail -1 | cut -f1) 2026-07-01T01:15:50+00:00 rc=7 line=6567 cmd=return ${issues}
tomspark wrote:
That err-trap log is exactly what I needed — rc=1 line=4853 confirms the exact failure point. The backup tool crashes while estimating how much data to copy, before it even tries to create the archive. This happens because a directory it looks for changed when you restructured your storage. Confirmed bug on our end. While we get the fix into the next update, try triggering the backup from the dashboard instead: Settings → Backups → Run Backup. That path goes straight to the archive step without the check that's failing. Let me know if the dashboard button also errors.
Chris wrote:
Owed you this update — the fix shipped and nobody came back to tell you. Sorry about the silence. Tom landed it in v1.6.402 on 20 July. One correction to the diagnosis you were given: your storage restructure wasn't the cause. When no module has a data/ folder, that glob stays literal, du exits 1, and under the shell's strict mode the whole backup died mute. It's now non-fatal — the size line was only ever a nicety, never a gate. The same release also gave CLI backups the consistent database dumps that dashboard backups used to get on their own, so you can drop the dashboard workaround. sudo sparkbox upgrade, then run your backup again. — Chris