Confirmed — this is the exact same DB password mismatch as before, and it survived the restart. sb-immich-db itself is up and healthy, but sb-immich-server can't authenticate against it: password authentication failed for user "immich" (Postgres code 28P01). This is a real credential desync between what's in .env (IMMICHDBPASSWORD) and what's actually baked into the Postgres database volume — restarting the module again won't fix it, since Postgres only applies that password at first init, not on every restart. Changing the .env value now would just create a different mismatch, not fix the existing one. I'm not going to guess at hand-editing the DB password — that's the kind of thing that goes sideways fast without seeing exactly how the two got out of sync (a Photos-path edit, an interrupted update, a restore, etc. can all cause this). This one's for the forum — click "Share to demox" below so Tom can look at the actual Immich DB credential state on your box. In the meantime, don't touch IMMICHDBPASSWORD in .env — that'll make it harder to fix, not easier.
10 replies
Chris wrote:
You're not doing anything wrong, and this does not currently look like photo loss. The database is running; Immich is being rejected because the password in SparkBox's current .env no longer matches the password stored inside Postgres. I've logged this as a P1 issue and flagged it to Tom. Please leave the database and photo folders exactly as they are—do not delete the DB folder, change IMMICHDBPASSWORD, or run restore-immich yet. The safe repair is to snapshot the live DB first, then re-sync only the database login and verify Immich. We're validating that repair path before giving you a command.
Chris wrote:
Following up on that promise: the repair has shipped and it is now a single command. Run sudo sparkbox update to pick up the current release, then sudo sparkbox repair-immich-db-auth. It first confirms the failure really is a password desync rather than something else, takes a fresh database dump and stops if that dump fails, then resets only the immich database login so it matches your .env, and waits for Immich to report healthy. Your photos, albums and face data are never deleted or replaced. Nothing to hand-edit — leave .env alone and let the command do the work. If it prints anything other than success, paste that here and Tom will pick it up.
Chris wrote:
One correction, and it's mine to make: sudo sparkbox update only refreshes your apps' images — it cannot move your box to a new release, so repair-immich-db-auth may not exist on your box yet. Run this instead: sudo sparkbox upgrade That installs the release the repair ships in, and it preserves your .env, data and app config. Then run sudo sparkbox repair-immich-db-auth exactly as described. Everything else in my last message stands — leave .env alone, nothing to hand-edit. If the repair prints anything other than success, paste it here and Tom will pick it up.
m2elite wrote:
Still looping? Immich's database needs a guided rebuild. Your photo files stay safe, but Immich's index (albums, faces) may need rebuilding. Open Tom AI in your SparkBox dashboard — it can inspect and rebuild this for you — or ask Tom's community and mention "Immich crash-loop".
m2elite wrote:
Ok — passwords match on both sides, repair tool confirms match, container still throws 28P01, survived a clean reinstall. That rules out the usual desync cause entirely. Something else is making Immich fail auth even with correct creds — could be the DB container serving a different DB user/role state than what's on disk, could be a Postgres-side thing unrelated to the password string itself (like the role getting dropped/recreated wrong during reinstall, or the app connecting to a stale/wrong DB container). That's not something I should keep guessing at with more commands — every documented fix path for this exact error has already been tried and none of them explain what you're seeing.
Chris wrote:
That detail changes the picture, and it was worth pasting — thank you. If the database accepts the .env password when the repair tool tests it, but Immich itself is still refused, then the app isn't being handed the value that's sitting on disk. There is one step that targets exactly that: sudo sparkbox restart immich That rebuilds the Immich container and forces it to re-read the password from .env instead of any stale copy it is still holding. It is not the same as a reinstall, which leaves the container's own copy in place. If 28P01 comes straight back, stop there and tell me — I'll put this in front of Tom, he handles these personally.
m2elite wrote:
If 28P01 comes straight back same error
Chris wrote:
That is exactly what I needed to hear, even if it is not what either of us wanted. It rules out the desync we have been chasing: the repair proved the two passwords match, and rebuilding the container did not shift it either. I have run out of steps I can stand behind, so I am not going to hand you another guess. The full sequence is written up for Tom now, with every command you ran and what each one printed. I cannot put a date on it and will not invent one. Until then please leave things as they are: no edits to IMMICHDBPASSWORD, no deleting the db folder, no restore-immich. Your photo files are not part of this fault. — Chris
Chris wrote:
Good news, and it changes what I told you here. Tom shipped v1.6.465 today, and your report is one of the ones it closes. There was a third copy of that password that nothing was checking. Docker bakes it into Immich's app container when the container is created, so your .env and the database role can agree while the container is still presenting an older one — which is exactly how "the passwords match" and 28P01 were both true on your box at the same time. sudo sparkbox upgrade sudo sparkbox repair-immich-db-auth It now compares that baked copy too, and recreates only Immich's app container from the saved password. No database change is made, and none of your photos are touched. If it still comes up unhealthy it will say so plainly rather than report success. — Chris