I got a new pc to run my sparkbox server. I installed sparkbox on it. On my previous server, i disconnected my das to not backup the media, made a backup through console so it was unencrypted, it was 2.6gb. Had tons of issues trying to use that, missing vpn settings etc Tried again and it was 6.8GB, using that with restore in console everything seems great, except gluetun fails and it reverts back. I’ve tried it with the old server down in case its an issue with 2 devices on my wireguard key, still no success Not sure how to get things transferred… Secondary question, I've had my das mounted at opt/sparkbox/data but i’m still having to umount for updates or else they fail. Am i better off setting the media root to the default hdd location linux assigns it?
10 replies
Chris wrote:
Hey Frosty! On the drive question: yes, that's the fix. Mount your DAS at wherever Linux normally puts it (not directly on top of /opt/sparkbox/data), then point Settings - Media Root at that path instead. Updates need to move things under /opt/sparkbox/data, and a drive mounted right at that exact spot blocks the move - that's exactly the unmount-for-updates trap you're hitting. For gluetun after the restore, start with 'sparkbox logs sb-gluetun' to see the real error. If it looks like stale VPN state carried over from the old box, this resets it cleanly: 'sparkbox down', then 'rm -rf /opt/sparkbox/modules/media/config/gluetun', then 'sparkbox up'. Paste back what the logs say if that doesn't clear it.
Frosty wrote:
the logs seem to be looping this error between shutting down and starting up a few times 026-08-07T01:38:02-05:00 ERROR VPN settings: provider settings: port forwarding: port forwarding cannot be enabled: value is not one of the possible choices: nordvpn must be one of perfect privacy, private internet access, privatevpn or protonvpn 2026-08-07T01:38:02-05:00 INFO Shutdown successful I do use protonvpn with port forwarding selected for my wireguard config and previously had to remove a firewall 10.0.0.0/8 from the media config. This should be visible in my history on demox if needed. I haven't had issues since ~$ sparkbox down [INFO] Stopping SparkBox... /usr/local/bin/sparkbox: line 2686: /opt/sparkbox/state/hw-dri-gids: Permission denied [+] down 3/3 ✔ Container sb-npm Removed 3.2s ✔ Container sb-portainer Removed 0.2s ✔ Container sb-homepage Removed 0.2s [+] down 1/1 ✔ Container sb-dashboard Removed 10.2s [OK] SparkBox stopped. joseph@joseph-7090:~$ rm -rf /opt/sparkbox/modules/media/config/gluetun rm: cannot remove '/opt/sparkbox/modules/media/config/gluetun/servers.json': Permission denied joseph@joseph-7090:~$
Chris wrote:
Two separate things here. First, those permission-denied errors: sparkbox down and rm both need sudo in front of them (sudo sparkbox down, sudo rm -rf ...) since those files are owned by the containers, not your user - that's why they're failing, not a real problem with the commands. Second, and this is the actual cause of the loop: when VPNPROVIDER isn't set in .env, SparkBox quietly falls back to nordvpn, and NordVPN doesn't support port forwarding, so gluetun refuses to start with port forwarding on - that matches the error exactly. Check /opt/sparkbox/.env for a line VPNPROVIDER=protonvpn - if it's missing or blank after your restore, add it, save, then sudo sparkbox restart media. That firewall change you made before should still be fine to leave as-is.
noahlol01 wrote:
Pretty sure you need sudo before rm -rf /opt/sparkbox/modules/media/config/gluetun
Frosty wrote:
Should vpn provider be included in the backup tho? Also it said "[ERROR] Restore applied but services failed to start. Rolling back." so if i change it in the .env now will that even fix it? or would i then have to restore again which would just cause the same issue...
Chris wrote:
Good questions. Yes, VPNPROVIDER lives in your .env file, so it's part of any full backup, nothing extra needed there. "Rolling back" means SparkBox noticed the services couldn't start and automatically reverted your box back to how it was right before you ran restore, so nothing's lost, you're just sitting on the pre-restore setup again for now. Editing .env right now won't help since that's the pre-restore file, not the restored one. Before trying restore again, check the OLD box's .env for a VPNPROVIDER=protonvpn line. If it's there, restoring again should work now that you know what to look for. If it's missing there too, add it, take a fresh backup, then restore that one instead.
Frosty wrote:
it's there in the old one. i can make a new backup ig and try again
Chris wrote:
Sounds like a solid plan — with VPNPROVIDER=protonvpn confirmed in the old box's .env, a fresh backup taken now should carry that setting over and let gluetun start cleanly on restore instead of looping. Give it a shot, and if it still rolls back or gluetun throws errors afterward, paste the sb-gluetun logs here and we'll keep digging. Good luck with the new server!
Frosty wrote:
same issue again WARN] This will overwrite current configuration! Continue? [y/N] y [INFO] Stopping SparkBox... [INFO] Restoring from backup... [INFO] Consistent database copies are in this backup but node is unavailable — apps restored from file-level copies. [OK] Restore complete. Starting SparkBox... [+] up 1/1 ✔ Container sb-adguard Running 0.0s [+] up 3/3 ✔ Container sb-portainer Started 0.3s ✔ Container sb-homepage Started 0.3s ✔ Container sb-npm Started 0.4s [+] up 1/1 ✔ Container sb-dashboard Started 0.3s [+] up 5/5 ✔ Container sb-jellyfin-media Running 0.0s ✔ Container sb-deunhealth Running 0.0s ✔ Container sb-bazarr Running 0.0s ✘ Container sb-gluetun Error dependency gluetun failed to start 0.5s ✔ Container sb-seerr Started 0.0s dependency failed to start: container sb-gluetun is unhealthy [+] up 1/1 ✔ Container sb-tailscale Running 0.0s [ERROR] Restore applied but services failed to start. Rolling back. [WARN] Compose file not found for module: core [WARN] Compose file not found for module: dashboard
Chris wrote:
That rollback message means SparkBox caught the failure and safely put you back on your working setup - nothing broken. This time the log doesn't show why gluetun itself failed, just that it did. Can you run sudo sparkbox logs sb-gluetun right after a restore attempt and paste what it says? That'll tell us if it's the same port-forwarding/provider issue as before or something new this time.