I ran the installer, but when i visit the dashboard to enter the bootstrap token, I enter the token and a password but no matter how many times i wait i still get "Another first-run claim is in progress. Retry in a few seconds.". I have uninstalled and re-installed multiple times but im not understanding what i did wrong.
7 replies
tomspark wrote:
Welcome to the DXP — and don't worry, you didn't do anything wrong. This is a known glitch where the dashboard's session folder permissions stop the first-run claim from finishing, so it gets stuck on 'in progress' forever no matter how long you wait. Two commands over SSH clear it: sudo chown -R 1000:1000 /opt/sparkbox/state sudo docker restart sb-dashboard Give it ~20 seconds to come back up, then reload the dashboard page. Because you've reinstalled a few times, grab the CURRENT token first so you're entering the right one: sudo sparkbox bootstrap-token Enter that token plus your password and it should go straight through. If it somehow still sticks, paste the output of: sudo docker logs sb-dashboard --tail 30 and I'll take it from there. You're almost in!
AntoxicDWA wrote:
I did the steps, but now I get "Failed to save password. Try again." no matter how many times i try: Here are the logs, clearly showing some sort of permission error setting a password [2026-06-26T01:48:10.199Z] [INFO] SparkBox Dashboard running on port 8443 [2026-06-26T01:48:10.201Z] [INFO] SBROOT: /app [2026-06-26T01:48:10.202Z] [INFO] License tier (cached): unlicensed [2026-06-26T01:48:10.278Z] [INFO] Backup encryption: dedicated key [health-report] Weekly report scheduler started (Sundays 8 AM). [knowledge-miner] Initialized. Daily mining at 4:00 AM. [scheduler] Cron job started: 0 4 [scheduler] SparkBox-self-update daily check scheduled (05:00). [2026-06-26T01:48:10.795Z] [INFO] [perms] migrated .env-hash from 664 to 600 [2026-06-26T01:48:10.796Z] [INFO] [perms] migrated authelia-admin-password.txt from 664 to 600 [2026-06-26T01:48:10.796Z] [INFO] [perms] migrated duplicati-admin-password.txt from 664 to 600 [2026-06-26T01:48:10.796Z] [INFO] [perms] migrated filebrowser-admin-password.txt from 664 to 600 [2026-06-26T01:48:10.796Z] [INFO] [perms] migrated first-login.txt from 664 to 600 [2026-06-26T01:48:10.797Z] [INFO] [perms] migrated gotify-admin-password.txt from 664 to 600 [2026-06-26T01:48:10.797Z] [INFO] [perms] migrated install-meta.conf from 664 to 600 [2026-06-26T01:48:10.797Z] [INFO] [perms] migrated linkding-admin-password.txt from 664 to 600 [2026-06-26T01:48:10.798Z] [INFO] [perms] migrated metrics-history.json from 664 to 600 [2026-06-26T01:48:10.798Z] [INFO] [perms] migrated modules.conf from 664 to 600 [2026-06-26T01:48:10.798Z] [INFO] [perms] migrated pihole-admin-password.txt from 664 to 600 [2026-06-26T01:48:10.878Z] [INFO] [perms] migrated portainer-admin-password.txt from 664 to 600 [2026-06-26T01:48:10.879Z] [INFO] [perms] migrated qbittorrent-admin-password.txt from 664 to 600 [2026-06-26T01:48:10.880Z] [INFO] [perms] migrated telemetry-install-id.txt from 664 to 600 [2026-06-26T01:48:10.880Z] [INFO] [perms] migrated vaultwarden-admin-password.txt from 664 to 600 [2026-06-26T01:48:10.880Z] [INFO] [perms] state/ permission migration: 15 file(s) locked to 0600 [alerts] Service health monitor started (30s interval; safety floor active for all installs). [config] atomic .env write unavailable (EACCES); falling back to direct write — partial-write protection reduced [2026-06-26T01:48:43.486Z] [ERROR] Failed to save password Error: EACCES: permission denied, open '/app/.env' at async open (node:internal/fs/promises:637:25) at async Object.writeFile (node:internal/fs/promises:1219:14) at async updateUnlocked (/app/lib/config.js:151:3
tomspark wrote:
Perfect — that log is exactly what I needed, and we're one step from done. The error is 'EACCES: permission denied, open /app/.env' — same kind of permissions issue, just on the settings file this time. My earlier command fixed the state folder but not the .env file itself. One more: sudo chown 1000:1000 /opt/sparkbox/.env Then go back to the dashboard and set your password again — it'll save this time and let you in. If any other 'permission denied' shows up after that, run this to cover everything and restart: sudo chown -R 1000:1000 /opt/sparkbox sudo docker restart sb-dashboard That's the last hurdle — you're basically in. (And thanks for the clean logs; they made this quick.)
AntoxicDWA wrote:
Now I finally got in, but when i started installing the media center and all that, the install froze, and now i cant get back into the dashboard at all. Here are the logs again Error: EACCES: permission denied, open '/app/state/sessions/XyxRyuLyExQmyu6Us3EtU-U7hyie5gn.json.tmp.1.959e8be6' at async Object.open (node:internal/fs/promises:637:25) at async writeFileAtomic (/app/lib/atomic-write.js:81:18) Error: EACCES: permission denied, open '/app/state/sessions/Nth4DC5WE8gFy0q-AE2REXkUindidQn7.json.tmp.1.0bd5781a' at async Object.open (node:internal/fs/promises:637:25) at async writeFileAtomic (/app/lib/atomic-write.js:81:18) Error: EACCES: permission denied, open '/app/state/sessions/BxfoWCEfGssQfL4Hq7HeVyQAJcMPqwfJ.json.tmp.1.45e51217' at async Object.open (node:internal/fs/promises:637:25) at async writeFileAtomic (/app/lib/atomic-write.js:81:18) Error: EACCES: permission denied, open '/app/state/sessions/HiKpWVb5iLny-RiM-5oCsCuTFuIiVuqW.json.tmp.1.4e539aca' at async Object.open (node:internal/fs/promises:637:25) at async writeFileAtomic (/app/lib/atomic-write.js:81:18) Error: EACCES: permission denied, open '/app/state/sessions/0gooKo7OcmQKL0sP2T26Tk4ekaJIFGgg.json.tmp.1.f2246f70' at async Object.open (node:internal/fs/promises:637:25) at async writeFileAtomic (/app/lib/atomic-write.js:81:18) Error: EACCES: permission denied, open '/app/state/sessions/S8cNIvUeW1oHMOqFAejXW8Ci-r4NI0Ae.json.tmp.1.cc4a77af' at async Object.open (node:internal/fs/promises:637:25) at async writeFileAtomic (/app/lib/atomic-write.js:81:18) Error: EACCES: permission denied, open '/app/state/sessions/po9O2nWUJXn7HX2ahUjVL6NaCk25ZmaO.json.tmp.1.d9560f4d' at async Object.open (node:internal/fs/promises:637:25) at async writeFileAtomic (/app/lib/atomic-write.js:81:18) Error: EACCES: permission denied, open '/app/state/sessions/9AB6z44sZx8m4cIaAvHaCiA01UhjuFVZ.json.tmp.1.74edf113' at async Object.open (node:internal/fs/promises:637:25) at async writeFileAtomic (/app/lib/atomic-write.js:81:18) Error: EACCES: permission denied, open '/app/state/sessions/uJSKtTBzZ1lDBdHcFxu-LQykIKRUMjc.json.tmp.1.64956027' at async Object.open (node:internal/fs/promises:637:25) at async writeFileAtomic (/app/lib/atomic-write.js:81:18) Error: EACCES: permission denied, open '/app/state/sessions/kJ4JwcmRXRtiNeD-XtnhkWiOEm5nu6Oq.json.tmp.1.d98720a0' at async Object.open (node:internal/fs/promises:637:25) at async writeFileAtomic (/app/lib/atomic-write.js:81:18)
tomspark wrote:
Ah — same permissions gremlin, and now I can see the full shape of it: when SparkBox installs something, that operation runs as the admin user and recreates files in the session folder owned by root, which locks the dashboard back out (it runs as a different user). Get back in with these two — this time on the whole folder: sudo chown -R 1000:1000 /opt/sparkbox sudo docker restart sb-dashboard Wait ~20s and reload — you'll be back in, and your media install most likely kept going in the background, so check the Apps page once you're in. Full honesty: this is a real bug on our end, specific to UGOS — the permissions don't stick through an install, so it can lock you out again after the next big operation. If that happens, those same two commands recover it every single time. I'm flagging it hard to get a proper fix so you're not babysitting it. Sorry for the rough start — you've basically stress-tested our worst onboarding bug, and the fix is squarely on us, not you.
AntoxicDWA wrote:
This is getting a little frustrating, every action I’m doing causes a crash again, then logging in sometimes doesn’t work again I get a toast error showing “Could not load services” is there a way to get this back on track so I don’t have to keep hopping back to the terminal and fixing things any action I make?
tomspark wrote:
Totally fair to be frustrated — babysitting the terminal isn't acceptable, so let's stop the whack-a-mole for good. The reason it keeps coming back: each SparkBox action recreates files owned by the root user, which locks the dashboard (a different user) out again. This command makes the dashboard's access permanent so it survives EVERY future action. Over SSH: sudo apt install -y acl sudo setfacl -R -m u:1000:rwx -m d:u:1000:rwx /opt/sparkbox sudo docker restart sb-dashboard The key part is the 'd:' bit — it tells the system 'always grant the dashboard access to anything created in here from now on', so new root-owned files can't lock you out anymore. After this you shouldn't have to touch the terminal again — enable apps, change settings, all of it should just work. If that setfacl line ever says 'Operation not supported', tell me and I'll switch you to the alternative (a tiny background job that keeps the permissions healed automatically). And thanks for sticking with it through this — you've found a real rough edge on UGOS that we're fixing properly.