Vielleicht hatten auch einige das Problem das Immich Anfang Juli seinen Dienst eingestellt hat bzw. nicht mehr startet.

Mich hat das getroffen und ich habe etwas nachgeforscht. Hier mal die Lösung falls die jemand braucht. Scheint so das Immich ein neues Postgres braucht und das die Postgres Datenbank emigriert werden muss.

Das ist recht einfach und kostet nur ein paar Minuten.

Backup der Docker machen!

1. Dazu geht man zum Tab mit den Dockercontainern und stopt Postgres und Immich.

2. Dann editiert man die Einstellungen des Postgres Containers.

3. In den Einstellungen aktivier man zuerst die Advanced view

4. Dann sucht man nach einer Zeile in der folgendes steht: tensorchord/pgvecto-rs:pg16-v0.3.0

5. Diese Zeile ersetzt man mit: ghcr.io/immich-app/postgres:16-vectorchord0.3.0-pgvectors0.3.0

6. Apply und warten. Das kann länger dauern. Einfach einen Kaffee trinken.

7. Dann sollte Postgres wieder laufen (man kann sich ja die Logs anschauen) und man startet Immich und das sollte wieder via Webinterface erreichbar sein.

Das ganze ist auch nicht auf meinem Mist gewachsen sondern ich habe das von hier von Ayashi33: Klick mich

Viellicht hilft es jemandem. Fals schonmal gepostet bitte ich um Verzeihung, ich bin hier gerade nicht so aktiv da ich jetzt mit 53 nochmal Nachwuchs bekommen habe. Ich bin ein Sugar Daddy

Gruss,
Joerg

Thank u bro so much

danke für den Tipp, ich hatte das Repo geändert und Immich lief danach (ich nutze das noch nicht wirklich produktiv sondern nur ab und zu zum Testen).

Heute wollte ich im Zusammenhang mit diesem neuen Thread nochmal sehen welche Version ich habe, aber mein Immich läuft nicht mehr wieder mal.

Heute nacht hatte ich noch eine Update Benachrichtigung vom Server....Habt ihr das Problem heute auch?

Ich nutze ghcr.io/imagegenius/immich:openvino - das sollte doch noch eine verfügbare Variante sein, oder?

Immich-Log:

Node.js v24.15.0
(node:2693) ExperimentalWarning: WASI is an experimental feature and might change at any time
(Use node --trace-warnings ... to show where the warning was created)
node:internal/process/promises:394
    triggerUncaughtException(err, true /* fromPromise */);
    ^
Error: connect EHOSTUNREACH 192.168.178.6:5433
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1705:16) {
  errno: -113,
  code: 'EHOSTUNREACH',
  syscall: 'connect',
  address: '192.168.178.6',
  port: 5433
}

postgres-Log:

2026-07-29 08:00:24.938 GMT [1] LOG:  skipping missing configuration file "/var/lib/postgresql/data/postgresql.override.conf"
2026-07-29 08:00:24.939 GMT [1] LOG:  skipping missing configuration file "/var/lib/postgresql/data/postgresql.override.conf"
2026-07-29 10:00:26.474 CEST [1] LOG:  starting PostgreSQL 16.10 (Debian 16.10-1.pgdg12+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14+deb12u1) 12.2.0, 64-bit
2026-07-29 10:00:26.475 CEST [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2026-07-29 10:00:26.475 CEST [1] LOG:  listening on IPv6 address "::", port 5432
2026-07-29 10:00:26.509 CEST [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2026-07-29 10:00:26.544 CEST [34] LOG:  database system was shut down at 2026-07-29 10:00:22 CEST
2026-07-29 10:00:26.564 CEST [1] LOG:  database system is ready to accept connections
2026-07-29 10:03:49.765 CEST [41] LOG:  invalid length of startup packet
2026-07-29 10:04:21.910 CEST [42] LOG:  invalid length of startup packet
2026-07-29 10:05:26.642 CEST [32] LOG:  checkpoint starting: time
2026-07-29 10:05:26.663 CEST [32] LOG:  checkpoint complete: wrote 2 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.002 s, sync=0.003 s, total=0.022 s; sync files=3, longest=0.003 s, average=0.001 s; distance=0 kB, estimate=0 kB; lsn=1/52B2BA68, redo lsn=1/52B2BA30
Using SSD storage

PostgreSQL Database directory appears to contain a database; Skipping initialization

Die DB läuft, der Port horcht (ja, auf 5433).

....das Update auf Immich 3.1.0 bzw. das aktuelle node.js ist "schuld":

Ausgangslage bei mir war (lief ja bislang):

• immich läuft auf custom br0 mit eigener IP 192.168.178.249:8080

• postgres-immich läuft auf der unraid-IP im Bridge Modus und angepasstem Port: 192.168.178.6:5433

• redis ebenfalls 192.168.178.7:6379

• also alles im gleichen IP-Netz, Ports passen

Das führte aber nach dem Update zu obigem Fehler.

[Der vom Standard abweichende Postgres-Port 5433 statt 5432 ist natürlich nicht das Problem]

Das Node.js v24 scheint jetzt strikter zu arbeiten und das Routing zur DB hat daher nicht mehr funktioniert, Zitat Gemini:

Das neue Node.js (v24) im aktuellen Immich-Update wurde im Bereich Netzwerksicherheit massiv verschärft:

• Wenn ein Container in br0 (mit eigener LAN-IP) versucht, die Unraid-IP anzusprechen, schickt er Datenpakete an den Unraid-Host.

• Der Unraid-Host leitet diese an das interne Docker-Netzwerk (bridge) weiter.

• Node.js v24 erkennt diese "Umlenkung" über das Host-Gateway (Asymmetric Routing) und stuft die Antwortpakete aus Sicherheitsgründen als manipuliert oder ungültig ein. Es bricht die Verbindung sofort hart mit EHOSTUNREACH ab. Andere Container ignorieren diesen Umweg einfach – Immich blockiert ihn aktiv. [1, 2]

Den postgres-container ebenfalls in custom br0 zu setzen (auf IP 192.168.178.251) hat geholfen, jetzt startet immich wieder 😃

Jetzt kommt aber noch die nächste Fehlermeldung bzgl. Redis:

Error: connect EHOSTUNREACH 192.168.178.6:6379

at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1705:16) {

errno: -113,

code: 'EHOSTUNREACH',

syscall: 'connect',

address: '192.168.178.6',

port: 6379

}

Das ist dann der Redis-Container, den ich allerdings auch z.B. für Paperless (192.168.178.6:8000) benötige...

Da ich nicht alle container auf eigenen IPs laufen lassen kann/möchte, ist die Frage, was jetzt zu tun wäre...

Gemini schlägt vor, den immich container parallel manuell ins bridge-Netzwerk zu hängen ("docker network connect bridge [Dein_Immich_Container_Name]"), das hatte er auch schon für die postgres-db vorgeschlagen, und dann die docker Bridge 172.17.0.1 als host für postgres/redis einzutragen. Alternativ schlägt er noch das Plugin "docker net connect" vor, welches ich allerdings nicht finde...gibt's scheinbar nicht (mehr) oder gab es nie?

Wenn ich redis direkt auf 172.17.0.1 oder 172.17.0.10 (seine aktuelle interne IP) im immich container konfiguriere, kommt:

Error: connect ETIMEDOUT

at Socket.<anonymous> (/app/immich/server/node_modules/.pnpm/[email protected]/node_modules/ioredis/built/Redis.js:183:41)

at Object.onceWrapper (node:events:630:28)

at Socket.emit (node:events:509:28)

at Socket._onTimeout (node:net:610:8)

at listOnTimeout (node:internal/timers:605:17)

at process.processTimers (node:internal/timers:541:7) {

errorno: 'ETIMEDOUT',

code: 'ETIMEDOUT',

syscall: 'connect'

}

Immich erreicht die bridge also nicht.

Der manuelle Weg, immich zusätzlich ins bridge Netzwerk zu hängen, klingt für mich allerdings, als würde das keinen restart des Containers überleben, oder?

Gemini schlägt noch eine Custom-bridge vor, aber das Grundproblem von node.js wäre damit doch auch nicht gelöst, oder?

Hat jemand noch eine Idee oder hat eine Erklärung dafür?

Das ganze läuft übrigens auf unraid 6.12.15, falls sich da seitdem grundlegend etwas geändert haben sollte.

Klar könnte ich auch noch eine IP für Redis spendieren und paperless kommt wahrscheinlich damit klar, aus der bridge (paperless) ins br0 zu kommunizieren...

Ich könnte natürlich auch einfach immich auf der bridge laufen lassen und den Port 8080 abändern...

Aber das eigentliche Thema der Docker-Netzwerke und -Zugriffe ist damit ja nicht vom Tisch - hier bin ich offenbar noch nicht wirklich im Thema, bin eher froh, dass die container alle laufen auf dem unraid host oder eigenen IPs ;)

Edited July 30Jul 30 by _alo_

Du kannst sicherlich lange rumprobieren, aber es gibt eine ganz einfache Lösung:

Vermeide die Bridge und gib allen Dockercontainer eine feste IP im br0/eth0 und du hast keine Probleme mehr.

1 hour ago, Bigbrother said:

Vermeide die Bridge und gib allen Dockercontainer eine feste IP im br0/eth0 und du hast keine Probleme mehr.

Das ist mir schon klar, dass das geht aber ist das jetzt wirklich das Ziel? Gibt’s da Docker seitig keine andere geeignete Lösung?