Just set up SparkBox and logged in, everything worked great. Very much looking forward to using this very cool new service. Clearly, tons of hard work has gone into it. Dashboard, Homepage, and NPM all report as Up (healthy). Portainer reports as Up for 7 minutes, then status stalls, and does not not indicate (healthy). SSH'ing into SparkBox, running docker ps, Portainer is running and status is not stalled. Stall of Portainer status appears to only be on the Dashboard. Unable to log in to Portainer.io (:9000) using "admin" and SparkBox generated password. Restarted Portainer, did not fix the issue. Thx again, very cool.
15 replies
tomspark wrote:
This is on us — patched in v1.6.68 (just shipped). The Portainer admin-password file got bcrypt-hash-generated as an empty file during your install, which sent Portainer into its first-run wizard. That wizard times out at ~5 minutes, which matches your "Up for 7 minutes, then status stalls" exactly. Update the dashboard to v1.6.68, then SSH in and run: sudo /opt/sparkbox/sparkbox up The widened self-heal will detect the broken file, regenerate the hash, and wipe the wizard-expired Portainer DB so the new admin actually takes. Your new password will be in state/portainer-admin-password.txt afterward. Thanks for the detail — the host-vs-dashboard docker ps comparison pinpointed it.
sparkboxfan wrote:
Sorry, the fix did not work for me. Installed the update to 1.6.68 - all good. SSH'd in and ran sudo /opt/sparkbox/sparkbox up Waited 5 min, just to be sure. All containers reporting Up and (healthy). Portainer reporting just Up. Still cannot log into Portainer.io (:9000) The SparkBox generated password in /opt/state/portainer-admin-password.txt was not wiped and re-generated. It is still the same as it was previously.
tomspark wrote:
Damn — sorry, that's on me. The self-heal in v1.6.68 detects an empty/missing password hash, but if the file from your original install has a non-empty (stale) hash, my regen logic skips it. Need two things to repro + ship a v1.6.69 patch this morning: (1) sudo head -c 20 /opt/sparkbox/state/portainer-admin-password.txt && echo (just the first 20 chars so I can see the format), and (2) sudo docker logs sb-portainer --tail 80. Patch will force-reset the file regardless of contents when Portainer's DB is post-wizard-expired.
tomspark wrote:
The self-heal didn't fire because the file already existed — try sudo rm /opt/sparkbox/state/portainer-admin-password.txt && sudo /opt/sparkbox/sparkbox up to force a regenerate, then check the new password in that file and try logging in as admin.
tomspark wrote:
Looks like your latest reply got auto-modded — the mod removes posts that paste real per-install secrets (long random strings in .env like SBSESSIONSECRET / SBBACKUPKEY). Treat those like passwords and redact before sharing publicly. Quick recap: v1.6.68's self-heal skips regen when the password file already exists. Manual workaround that forces it: sudo rm /opt/sparkbox/state/portainer-admin-password.txt sudo /opt/sparkbox/sparkbox up Wait ~30 seconds, then sudo cat /opt/sparkbox/state/portainer-admin-password.txt — use that as the admin password at http://your-host:9000. If it still doesn't take after that, paste sudo docker logs sb-portainer --tail 80 (no .env contents needed — the docker logs are safe) and I'll see Portainer's side of it.
GamerX06 wrote:
I am running into this issue as well and im on the latest version. 2026/05/10 09:41AM INF github.com/portainer/portainer/api/cmd/portainer/main.go:321 encryption key file not present | filename=/run/secrets/portainer 2026/05/10 09:41AM INF github.com/portainer/portainer/api/cmd/portainer/main.go:360 proceeding without encryption key | 2026/05/10 09:41AM INF github.com/portainer/portainer/api/database/boltdb/db.go:137 loading PortainerDB | filename=portainer.db 2026/05/10 09:41AM FTL github.com/portainer/portainer/api/cmd/portainer/main.go:481 failed getting admin password file | error="could not get the contents of the file '/run/secrets/portaineradminpassword'" 2026/05/10 09:42AM INF github.com/portainer/portainer/api/cmd/portainer/main.go:321 encryption key file not present | filename=/run/secrets/portainer 2026/05/10 09:42AM INF github.com/portainer/portainer/api/cmd/portainer/main.go:360 proceeding without encryption key | 2026/05/10 09:42AM INF github.com/portainer/portainer/api/database/boltdb/db.go:137 loading PortainerDB | filename=portainer.db 2026/05/10 09:42AM FTL github.com/portainer/portainer/api/cmd/portainer/main.go:481 failed getting admin password file | error="could not get the contents of the file '/run/secrets/portaineradminpassword'"
GamerX06 wrote:
I tried the factory reset and got nerd@NerdPlex:/opt/sparkbox/modules/core$ sparkbox up / | | | | ) \ \| ' \ / | '| |/ / \ / \ \/ / ) | |) | (| | | | <| |) | () < |/| ./ \,|| ||\\/ \//\\ || SparkBox v1.6.81 - Self-Hosted Privacy Stack Created by Tom Spark | youtube.com/@TomSparkReviews [INFO] Starting SparkBox... [INFO] Active modules: core dashboard [INFO] .env changed since last up — recreating containers to pick up new values [+] up 3/3 ✔ Container sb-portainer Started 11.2s ✔ Container sb-npm Started 11.2s ✔ Container sb-homepage Started 11.2s /usr/local/bin/sparkbox: line 1259: /opt/sparkbox/state/.env-hash: Permission denied [OK] SparkBox is running! [INFO] Portainer secret missing or invalid — regenerating... nerd@NerdPlex:/opt/sparkbox/modules/core$ sudo cat /volume1/docker/sparkbox/state/portainer-admin-password.txt cat: /volume1/docker/sparkbox/state/portainer-admin-password.txt: No such file or directory nerd@NerdPlex:/opt/sparkbox/modules/core$
tomspark wrote:
GamerX06 — two things going on for you. First: you ran sparkbox up without sudo. The Permission denied on .env-hash and the silent Portainer regen are both because the script can't write to /opt/sparkbox without root. Run sudo sparkbox up and the regen will actually land. Second: the password file lives at /opt/sparkbox/state/portainer-admin-password.txt, not /volume1/docker/sparkbox/state/ — that /volume1 path is for UGREEN-style installs only and your install is at /opt. Just shipped v1.6.82 that hard-fails the CLI when invoked without sudo so you get a clear 'use sudo' error up front instead of this half-failure. After it propagates: sudo sparkbox update && sudo sparkbox up, then sudo cat /opt/sparkbox/state/portainer-admin-password.txt for the admin login. sparkboxfan — did the sudo rm + sudo sparkbox up workaround land for you, or are you still stuck? If still stuck, paste sudo docker logs sb-portainer --tail 80 (docker logs are safe to share, no .env contents) and I'll see Portainer's side of it.
tomspark wrote:
Followup — shipped v1.6.82 yesterday with the root-cause fix for the silent half-fail you and GamerX06 hit. The CLI now hard-fails up front with a clear needs sudo error if it can't write to the install dir, instead of running through the regen block with all writes silently swallowed. sudo sparkbox update && sudo sparkbox up should land it. If you still see the broken admin password file after the update, the recovery is the same sudo rm + sudo sparkbox up I posted earlier — but you should now also see a clean error message if anything in that flow is missing perms.
GamerX06 wrote:
First off, THANK YOU for being an awesome human, second I think I was poking around with too many things and made things worse so I nuked it and started over. The Portainer seems stable now with no crashes, but I can't log into it with the generated credentials. nerd@NerdPlex:/mnt/e/Sparkbox$ sudo docker logs sb-portainer --tail 80 2026/05/10 06:30PM INF github.com/portainer/portainer/api/cmd/portainer/main.go:321 encryption key file not present | filename=/run/secrets/portainer 2026/05/10 06:30PM INF github.com/portainer/portainer/api/cmd/portainer/main.go:360 proceeding without encryption key | 2026/05/10 06:30PM INF github.com/portainer/portainer/api/database/boltdb/db.go:137 loading PortainerDB | filename=portainer.db 2026/05/10 06:30PM INF github.com/portainer/portainer/api/cmd/portainer/main.go:514 instance already has an administrator user defined, skipping admin password related flags. | 2026/05/10 06:30PM INF github.com/portainer/portainer/api/chisel/service.go:199 found Chisel private key file on disk | private-key=/data/chisel/private-key.pem 2026/05/10 18:30:26 server: Reverse tunnelling enabled 2026/05/10 18:30:26 server: Fingerprint (REMOVED) 2026/05/10 18:30:26 server: Listening on (REMOVED) 2026/05/10 06:30PM INF github.com/portainer/portainer/api/cmd/portainer/main.go:634 starting Portainer | buildnumber=21 goversion=go1.26.2 imagetag=2.41.0-linux-amd64 nodejsversion=v22.22.2 pnpmversion=10.27.0 version=2.41.0 webpackversion=5.105.0 2026/05/10 06:30PM INF github.com/portainer/portainer/api/http/server.go:370 starting HTTPS server | bindaddress=:9443 2026/05/10 06:30PM INF github.com/portainer/portainer/api/http/server.go:354 starting HTTP server | bindaddress=:9000
GamerX06 wrote:
i Ran this after Nuke and same results nerd@NerdPlex:/mnt/e/Sparkbox$ sudo sparkbox update && sudo sparkbox up [INFO] Pulling latest images for all enabled modules... [+] pull 3/3 ✔ Image jc21/nginx-proxy-manager:2.14.0 Pulled 1.0s ✔ Image portainer/portainer-ce:2.41.0 Pulled 1.1s ✔ Image ghcr.io/gethomepage/homepage:v0.9.13 Pulled 1.6s [+] pull 1/1 ✔ sparkbox-dashboard Skipped No image to be pulled 0.0s [INFO] Recreating containers... [+] up 3/3 ✔ Container sb-npm Started 10.9s ✔ Container sb-portainer Started 10.8s ✔ Container sb-homepage Started 10.9s [OK] Update complete. / | | | | ) \ \| ' \ / | '| |/ / \ / \ \/ / ) | |) | (| | | | <| |) | () < |/| ./ \,|| ||\\/ \//\\ || SparkBox v1.6.85 - Self-Hosted Privacy Stack Created by Tom Spark | youtube.com/@TomSparkReviews Network profile: private [INFO] Starting SparkBox... [INFO] Active modules: core dashboard [INFO] Prepared 2 module config dir(s) for PUID=1000 PGID=1000 [INFO] .env changed since last up — recreating containers to pick up new values [+] up 3/3 ✔ Container sb-homepage Started 11.1s ✔ Container sb-npm Started 11.0s ✔ Container sb-portainer Started 11.0s [OK] SparkBox is running!
tomspark wrote:
Stable on v1.6.85 now — good. The remaining issue is in your docker logs: "instance already has an administrator user defined, skipping admin password related flags." Portainer's database still has the old admin from before your nuke, and our regen logic skips when Portainer thinks an admin exists. One-time wipe to clear it: sudo docker stop sb-portainer && sudo rm -rf /opt/sparkbox/modules/core/config/portainer && sudo docker start sb-portainer Wait ~30 seconds, then run: sudo cat /opt/sparkbox/state/portainer-admin-password.txt Use that as your admin password at http://YOUR-NAS-IP:9000. The fresh boot reads the password file and creates a brand-new admin from it. Going to add a sparkbox portainer-reset command so this isn't a 3-step manual fix in a future version.
tomspark wrote:
Update on this one — shipped v1.6.99 with a fix: sudo sparkbox update sudo sparkbox repair-portainer The new repair-portainer command wipes Portainer's DB, regenerates the admin password, restarts the container, and verifies the new login actually works before exiting. New password lands in state/portainer-admin-password.txt. sparkbox doctor also got a [Portainer Auth] probe that flags 422/401 as a known class-level bug and points at repair-portainer. This is the rescue + detection layer, not the install.sh root-cause fix (still deferred to v1.7.x because that touches the install banner path). But anyone stuck right now has a one-command exit.
tomspark wrote:
Quick correction — turns out v1.6.99's repair-portainer had a silent-crash bug (caught it in the wild ~90 min after shipping). It actually DID the repair correctly but then crashed in the verify-login step before printing success, leaving you at a bare prompt. v1.6.100 (live now on the CDN) fixes the crash. If you ran v1.6.99 your Portainer is already fixed — the creds are sitting in state/portainer-admin-password.txt. sudo sparkbox update to grab v1.6.100 for the proper success/error reporting next time.
tomspark wrote:
Tom here with the actual root cause for your Portainer issue from back on the 9th. It was Portainer 2.41 silently changing --admin-password-file semantics — they now expect plaintext in that file, not bcrypt. SparkBox had been giving it bcrypt since v1.0. Every install since the 2.41 bump has been hitting it. Fix shipped in v1.6.101: sudo sparkbox update sudo sparkbox repair-portainer That wipes Portainer's DB and writes a fresh plaintext password the way 2.41 wants, then verifies login works before exiting. Full diagnostic credit to LaggyGamerZA 9024 — he ran the bcrypt-verify test that proved our hash gen was fine and the bug was on Portainer's side. Took us 3 days and 6 versions to land. Apologies for the chase.