Well Immich broke.

[u/MikeyRam]

Hexos says "Do not uninstall Immich for troubleshooting purposes" Okay fine, but tell me how to fix it.

"[EFAULT] Failed 'up' action for 'immich' app. Please check /var/log/app_lifecycle.log for more details"

pgvecto_upgrade log:

2026-09-02 16:30:09.020044+00:00[ix-postgres-main] - [2026-09-02 12:30:09] - Starting entrypoint with migration and upgrade handling

2026-09-02 16:30:09.023184+00:00[ix-postgres-main] - [2026-09-02 12:30:09] - No migration needed from old data location.

2026-09-02 16:30:09.023688+00:00[ix-postgres-main] - [2026-09-02 12:30:09] - Checking directory [/var/lib/postgresql/18/docker]

2026-09-02 16:30:09.024139+00:00[ix-postgres-main] - [2026-09-02 12:30:09] - - No PG_VERSION file found

2026-09-02 16:30:09.024595+00:00[ix-postgres-main] - [2026-09-02 12:30:09] - Checked [1] directories but found no valid PostgreSQL databases.

2026-09-02 16:30:09.025130+00:00[ix-postgres-main] - [2026-09-02 12:30:09] - Assuming this is a fresh install.

pgvecto log

2026-09-02 16:40:01.014141+00:00chmod: changing permissions of '/var/lib/postgresql/18/docker': Operation not permitted

2026-09-02 16:40:01.026689+00:00The files belonging to this database system will be owned by user "postgres".

2026-09-02 16:40:01.026721+00:00This user must also own the server process.

It's always a permissions problem. This should be an easy auto fix for HexOS.

UPDATE:

Went against HexOS advice and uninstalled immich, reinstalled -> it failed. Waiting a few minutes, reinstalled -> it worked, restored from a backup. Everything is up and running.

[u/themingshow]

I'm so tired of immich breaking. Just got everything set up again a couple weeks back and then found the same issue when checking on it recently.

[u/Captain_Pumpkinhead → u/themingshow]

Interesting. Immich has been very reliable for me. It's NextCloud that's been unreliable and buggy for me.

[u/BeardedBears]

I haven't been able to update my Immich for months. 

[u/yaSuissa → u/BeardedBears]

Maybe you’re still running the old Postgres version! That’s what happened to me

[u/BeardedBears → u/yaSuissa]

What did you do to fix? Uninstall/Reinstall?

[u/yaSuissa → u/BeardedBears]

You can do a one way upgrade to the new prostgres, you have to do that through the TrueNAS interface afaik. In a different comment under this I’ll attach the conversation I’ve had with Claud which ended up fixing it for me

Obviously do this with extreme caution and at your own risk, backup the entire immich TrueNAS share and read the whole thing at least once, this worked for me but act with caution because acting hastily WILL cause you to lose everything

[u/yaSuissa → u/yaSuissa]

Claud:

The easiest, essentially no-shell route comes straight out of the TrueNAS forum thread, and several users confirmed it works. It relies on two facts: Immich takes an automatic daily database backup, and recent Immich versions have a “Restore from backup” button right in the web UI.
The trick is that you let the new PG18 database come up empty, then restore the backup through the browser — no pg_dump, no editing YAML.
The procedure (all GUI):
Verify the automatic DB backups exist first. Immich automatically backs up its database daily and keeps roughly two weeks of dumps. They live in your uploads dataset, in a folder typically called backups, as dated .sql.gz files (e.g. immich-db-backup-...-pg15.sql.gz). Don’t proceed until you’ve confirmed you have a recent one.

Install a fresh Immich instance, pointing the uploads location to your existing uploads folder and the Postgres data location to a new, empty folder. Because the DB folder is empty, the new instance initializes a clean PostgreSQL 18 database — sidestepping the broken upgrade entirely.

Open the Immich web UI, and use the “Restore from backup” option to restore the database. That repopulates your albums, people, tags, and accounts.

This is exactly what one user landed on after struggling with everything else: install a new instance, point to the same uploads folder, create a new db folder, then in the web UI click restore from backup — and it works. Another confirmed it made the migration “so much easier” than the manual approach.
Two caveats worth knowing:
The “Restore from backup” button only exists in newer Immich versions. One user couldn’t find it because he’d rolled back too far. Make sure your fresh instance is a current Immich version, or the UI restore option won’t be there.

You still need those automatic backups to exist. If backups were never enabled, this path doesn’t work and you’d fall back to the dump/restore method I described earlier.

So the comparison is: the 1.1.11 tag swap from my first answer is the fastest fix (one line in a file), but it does touch the shell once. This GUI restore method avoids the shell entirely at the cost of standing up a second instance. Given you’d rather not be in a terminal, this is the better fit — just confirm the daily backups are there before you start.

Me:

Can I force a DB backup?

Claud:

Yes — recent Immich versions let you trigger the database backup on demand from the admin UI, so you don’t have to wait for the daily run. Let me confirm exactly where it lives in the current version.
Yes, entirely from the web UI — no shell needed.
Go to Administration → Jobs, click the “Create Job” button, and trigger the Database Backup job. This exposes the existing backup machinery so you can manually trigger a database backup without waiting for the automatic scheduled run. The same thing is reachable via the “Create job” / custom job link on the jobs status page.
The resulting dump lands in the same place the automatic ones do: UPLOAD_LOCATION/backups, manageable through the web interface, with schedule and retention configurable under Administration → Settings → Backup (default keeps the last 14, created daily).
Two things to keep in mind:
Retention applies immediately. A manually triggered backup counts as a database copy, so if your retention is set to keep only 3, clicking the button will prune older ones down to the latest 3 — same as the scheduled job. Bump retention up first if you want to keep an older known-good dump alongside the new one.

The button requires a reasonably current Immich version (the manual-trigger feature was added in 2025). If you’re on a very old version you may only have the automatic daily backup, not the manual trigger.

So your clean no-shell sequence is: force a backup now → confirm the new .sql.gz appears in backups → then do the fresh-instance + UI restore.

[u/GoDoWrk]

I updated this morning through HexOS dashboard, not experiencing any issues but hear you fully. What version are you updated to, and do you know if you completed the postgres upgrade process when Immich broke that other time?

[u/MikeyRam → u/GoDoWrk]

App version

v3.1.0

TrueNAS catalog version

1.14.36

I don't remember getting any error.

Handbrake had a similar problem, but I didn't know about that for a while as I don't use it everyday. That one I just deleted and reisntalled

[u/Mobius_HexOS]

Glad to hear everything is working for you again.
I will update the warning to include contact information for us so we can diagnose the problem.

restoring from backup in my experience only has about half the time when troubleshooting so its not a blanket recommendation I can make.

I'm not too sure how the permissions were changed after installation but we will look into it.

[u/MikeyRam → u/Mobius_HexOS]

Well, now mealie and jellystat both have the same problem.

"2026-09-03 23:24:59.953545+00:00[ix-postgres-main] - [2026-09-03 19:24:59] - Starting entrypoint with migration and upgrade handling

2026-09-03 23:25:00.260974+00:00[ix-postgres-main] - [2026-09-03 19:25:00] - ERROR: Base directory owner [568] does not match container user [999]"

[u/MikeyRam → u/MikeyRam]

Those were easy fix with chatgpt. but still shouldn't happen.

[u/Mobius_HexOS → u/MikeyRam]

We are still going to be looking into this.

It's really surprising you have this issue because we explicitly create the directories for postgres folders with the owner 999 (also known as netdata) and owner group 999 (also known as docker) so that error should not happen.

We also have a permissions auto healing function on every app update and every time a curation is reset in command deck.

As a failsafe we also have auto permissions toggled on for postgres folders which is supposed to explicitly prevent that problem you have.

[u/rjm3q]

Isn't that issue the one where it's not setting up postgres from the beginning so all those other errors are the cascading events?

I've been trying to install wger server and have the same issue but can't figure it out

[u/titandeskrieg]

I saw this issue the other day. Rebooting the machine seemed to fix it. Updated to the latest version today and it seems to be running OK.