Background, I recently installed a volume2 on my ugreen NAS and wanted to save the backups there. This is the end of the conversation with tomai after successfully moving the backup location. From TomAI: Okay, that's useful — no --encrypt flag exists at all in your CLI. Encryption isn't something you toggle; it's automatic based on whether the key resolves at runtime. So this isn't a flag you missed. That said — you're on v1.6.395, well past the fix, so it shouldn't silently fall back anymore. That plaintext file is genuinely off from expected behavior on your version. I'm not confident guessing further without seeing what actually happened at the moment it ran. Given: You're on a current build The key names exist in .env But you still got an unencrypted sparkbox-full-.tar.gz instead of .enc That's outside the known patterns I can diagnose confidently from here. Delete or secure that plaintext file for now (it's sitting on volume2 with your secrets in the clear), and click "Share to demox" below on this one — Tom's team should look at why a 1.6.395 box produced an unencrypted archive when the bug was supposed to be closed already.
5 replies
Chris wrote:
Good news — nothing's broken and your box is fine on v1.6.395. It comes down to which backup you used: the command-line backup always makes a plain, unencrypted file on purpose — that's why it prints that big 'UNENCRYPTED backup' warning when it finishes. The encrypted .enc backups are the ones made from the Backup option in your dashboard, which locks them with your own key. So nothing failed to encrypt — the command-line one just doesn't do it yet. That plain file does hold your secrets in the open, so keep it somewhere private, or delete it — it's only a copy, your real photos and files are untouched. If you'd like encrypted backups from here on, make them from the dashboard's Backup option.
Doc_Senna wrote:
The backup succeeds with sudo sparkbox backup, but fails with the UI backup. This message is in the backup center: Backups have been failing since 1h — Command failed: docker run --rm --user 0:0 --entrypoint /bin/bash -v /opt:/opt -v /volume1/sparkbox-data:/volume1/sparkbox-data -w /opt sparkbox-sparkbox-dashboard -lc set -uo pipefail hostroot="$1" tarpath="$2" rootsspec="$3" shift 3 mkdir -p "$(dirname "$tarpath")" farmdir="$(dirname "$tarpath")/.backup-roots.$$" rm -rf "$farmdir" mkdir -p "$farmdir" cleanup() { rm -rf "$farmdir"; } trap cleanup EXIT while IFS='=' read -r pfx abs; do [[ -n "$pfx" && -n "$abs" ]] || continue ln -s. This is what TomAI concluded: Everything's healthy — this isn't a crash-loop or a stuck container. The backup failure is isolated to the backup script logic itself. So here's where this stands: the backup job spins up a throwaway container, mounts /opt and /volume1/sparkbox-data, and tries to build a symlink farm mapping each backup "root" (your module configs, state, data dirs) before handing it to tar. It's dying somewhere in that setup — could be a bad root path in the list, a symlink collision, or something in how the roots-spec is being parsed. That's internal to the dashboard's backup code, not something I can fix from here (no tool reaches into that script), and not something a restart or fixmediapermissions touches. This is exactly the case to escalate — reproducible failure, healthy containers, same command dying twice. Click Share to demox below so Tom can see the full command + exit output. In the meantime your data's not at risk (nothing's actually being deleted, the job just isn't completing), but you don't have a fresh backup until this gets patched — so hold off relying on it for now. Commands I ran to move the backup file: sudo mv /opt/sparkbox/backups/ volume2/sparkbox-backups sudo In -s /volume2/sparkbox-backups /opt/sparkbox/backups
Chris wrote:
Good news first — nothing's broken and your backups are safe. You actually spotted the cause yourself. The dashboard backup runs inside a small sealed sandbox that can only see two places: your SparkBox folder and your media drive — it can't see volume2 at all. When you moved the backups folder onto volume2 and left a shortcut pointing there, the dashboard job follows that shortcut somewhere it can't reach and stops. The command-line backup runs right on the NAS, so it CAN reach volume2 — that's the whole difference. Storing dashboard backups on volume2 isn't something SparkBox supports out of the box yet, so that's what's tripping it up. Rather than have you undo it blind, I've flagged your setup to Tom — he handles these personally and can give you the safe steps for your box. Your sudo sparkbox backup is fine to keep using in the meantime.
Doc_Senna wrote:
Thank you Chris, just fyi at least for me your replies haven’t been triggering notifications like the tomspark account does. Might need to get that looked at too.
Chris wrote:
Thanks for the heads up on that — you're right, and it's a real gap. A reply should reach you the same way no matter which support account posts it, and right now mine aren't firing a notification for you. I've flagged it to Tom to get that sorted so you don't miss any replies. Really appreciate you catching it, and glad the backup piece makes sense now.