5432 scheint mir der Default-Postgres-Port zu sein. Da kann wohl der Immich-Server nicht zu seiner Datenbank connecten. Wieso, weiß ich nicht.
[TUT] IMMICH - Perfekte Alternative zur Foto-App
-
- Portainer
-
Willi -
December 22, 2024 at 7:28 PM
-
-
Ich habe mir nochmal über das Terminal angeschaut, welcher User die erstellen Dokumente in der docker immich DB besitzt. Es gibt noch einige mehr die mit der Installation mitkamen, sind aber ausnahmslos dnsmasq zugeordnet.
Über den Dateimanager im UGOS ist der Eigentümer des Immich-Ordners "db" "999" (Eigentümer). Hängt das irgendwie zusammen? Muss da mein adminuser stehen oder die User-Gruppe "admin"? Ich habe ja über die .yml den User: 1000:10 connected.
-
Sorry, keine Ahnung.
Ich denke eher, dass es am Netzwerk liegt. Liegt "immich_server" und "immich_postgres" zusammen in gleichen Netzwerk?
Bei mir heißt das Netzwerk "immich_default". Da gehören auch "immich_machine_learning" und "immich_redis" mit dazu.
The content cannot be displayed because you do not have authorisation to view this content.
Man muss ja erst mal hinkommen bevor man sich anmeldet. -
immich_postgres und immich_server sidn im selben Netzwerk. Von "immich_database" sehe ich allerdings weder auf deinem noch auf meinem Screenshot etwas.
The content cannot be displayed because you do not have authorisation to view this content. Das habe ich aber gerade auf der docker GUI noch gesehen:
The content cannot be displayed because you do not have authorisation to view this content. -
Ich würde ja mal prüfen, ob die DB läuft. Wenn nicht, ist es ganz schlecht mit einer Verbindung zu der.
-
Sorry, sollte "immich_postgres" heißen, nicht "immich_database". Hab's oben korrigiert.
Ich hab grad mal eine Konsole auf "immich_server" geöffnet, weiß allerdings nicht, wie man da die Erreichbarkeit der Datenbank testen kann. ping und telnet gibt es nicht und bei sowas wie "psql --host=192.19.0.2 --port=5432 --username=immichuser --list" bekomme ich keine Antwort. Bei mir funktioniert auf jeden Fall alles.
Aber vielleicht wissen ja andere mehr. -
vielleicht kann ja alter Mannseine Unterstützung präzisieren? Für mich als Laie scheint es klar zu sein, dass wenn die DB nicht läuft, dass man sie auch nicht erreichen kann.
-
Wenn ich jetzt deinen neuen Screenshot so sehe, klar, dann muss erstmal die Datenbank laufen. Steht was in deren Logs?
Edit: Bei mir steht im database-Abschnitt des Stacks:Code
Display Moredatabase: container_name: immich_postgres image: docker.io/tensorchord/pgvecto-rs:pg14-v0.2.0@sha256:90724186f0a3517cf6914295b5ab410db9ce23190a2d9d0b9dd6463e3fa298f0 environment: POSTGRES_PASSWORD: ${DB_PASSWORD} POSTGRES_USER: ${DB_USERNAME} POSTGRES_DB: ${DB_DATABASE_NAME} POSTGRES_INITDB_ARGS: '--data-checksums' volumes: - ${DB_DATA_LOCATION}:/var/lib/postgresql/data healthcheck: test: >- pg_isready --dbname="$${POSTGRES_DB}" --username="$${POSTGRES_USER}" || exit 1; Chksum="$$(psql --dbname="$${POSTGRES_DB}" --username="$${POSTGRES_USER}" --tuples-only --no-align --command='SELECT COALESCE(SUM(checksum_failures), 0) FROM pg_stat_database')"; echo "checksum failure count is $$Chksum"; [ "$$Chksum" = '0' ] || exit 1 interval: 5m start_interval: 30s start_period: 5m command: >- postgres -c shared_preload_libraries=vectors.so -c 'search_path="$$user", public, vectors' -c logging_collector=on -c max_wal_size=2GB -c shared_buffers=512MB -c wal_compression=on restart: unless-stopped
Weiß aber nicht mehr, ob dir das hilft und wo ich das her hatte. -
vielleicht kann ja alter Mannseine Unterstützung präzisieren?
Wie schaut, ob die läuft oder was meinst du? Brachte schon Benares, deren Container hat ein Logfile.
Schauen, ob die alle im gleiche Netzwerk sind, kam auch schon.
-
Im Logfile des portainer containers "immich_postgres" (running) steht folgendes:
Code
Display MoreUsing SSD storage The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale "en_US.utf8". The default database encoding has accordingly been set to "UTF8". The default text search configuration will be set to "english". Data page checksums are enabled. fixing permissions on existing directory /var/lib/postgresql/data ... ok creating subdirectories ... ok selecting dynamic shared memory implementation ... posix selecting default max_connections ... 100 selecting default shared_buffers ... 128MB selecting default time zone ... Etc/UTC creating configuration files ... ok running bootstrap script ... ok performing post-bootstrap initialization ... ok syncing data to disk ... ok initdb: warning: enabling "trust" authentication for local connections You can change this by editing pg_hba.conf or using the option -A, or --auth-local and --auth-host, the next time you run initdb. Success. You can now start the database server using: pg_ctl -D /var/lib/postgresql/data -l logfile start 2026-03-03 15:58:06.925 GMT [49] LOG: skipping missing configuration file "/var/lib/postgresql/data/postgresql.override.conf" 2026-03-03 15:58:06.925 GMT [49] LOG: skipping missing configuration file "/var/lib/postgresql/data/postgresql.override.conf" waiting for server to start....2026-03-03 15:58:06.954 GMT [54] LOG: skipping missing configuration file "/var/lib/postgresql/data/postgresql.override.conf" 2026-03-03 15:58:06.955 GMT [54] LOG: skipping missing configuration file "/var/lib/postgresql/data/postgresql.override.conf" 2026-03-03 15:58:06.983 UTC [54] LOG: starting PostgreSQL 14.19 (Debian 14.19-1.pgdg12+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14+deb12u1) 12.2.0, 64-bit 2026-03-03 15:58:06.984 UTC [54] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2026-03-03 15:58:06.990 UTC [55] LOG: database system was shut down at 2026-03-03 15:58:05 UTC 2026-03-03 15:58:06.995 UTC [54] LOG: database system is ready to accept connections done server started CREATE DATABASE /usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/* waiting for server to shut down....2026-03-03 15:58:07.607 UTC [54] LOG: received fast shutdown request 2026-03-03 15:58:07.608 UTC [54] LOG: aborting any active transactions 2026-03-03 15:58:07.615 UTC [54] LOG: background worker "logical replication launcher" (PID 62) exited with exit code 1 2026-03-03 15:58:07.615 UTC [57] LOG: shutting down 2026-03-03 15:58:07.635 UTC [54] LOG: database system is shut down done server stopped PostgreSQL init process complete; ready for start up. 2026-03-03 15:58:07.720 GMT [1] LOG: skipping missing configuration file "/var/lib/postgresql/data/postgresql.override.conf" 2026-03-03 15:58:07.720 GMT [1] LOG: skipping missing configuration file "/var/lib/postgresql/data/postgresql.override.conf" 2026-03-03 15:58:07.743 UTC [1] LOG: starting PostgreSQL 14.19 (Debian 14.19-1.pgdg12+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14+deb12u1) 12.2.0, 64-bit 2026-03-03 15:58:07.743 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432 2026-03-03 15:58:07.743 UTC [1] LOG: listening on IPv6 address "::", port 5432 2026-03-03 15:58:07.746 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2026-03-03 15:58:07.750 UTC [72] LOG: database system was shut down at 2026-03-03 15:58:07 UTC 2026-03-03 15:58:07.756 UTC [1] LOG: database system is ready to accept connectionsIn der Docker-GUI sehe ich aber folgendes:
The content cannot be displayed because you do not have authorisation to view this content. -
Oh je, weiß ich leider auch nicht. M.E. sieht alles gut aus.
-
Docker Netzwerk prüfen.
docker network inspect immich_default
Da sollten alle drin sein.
-
Alle anderen immich Container sind healthy. So auch immich_postgres, was das logfile auch bestätigt: "database system is ready to accept connections"
Ich kann aus dem JSON-Output für das Netzwerk "immich_default" auch nichts weiteres entnehmen
Code
Display More[ { "Name": "immich_default", "Id": "d26283313f8abbbbaf5fe2b9b79ab4705d9153335e480eb367c2a8cd0fda0bf3", "Created": "2026-03-04T11:40:56.721735273+01:00", "Scope": "local", "Driver": "bridge", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": null, "Config": [ { "Subnet": "172.29.0.0/16", "Gateway": "172.29.0.1" } ] }, "Internal": false, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": { "8ce57f29525a3dd89839defb311ed1d0a80ac38e05b512b4155af33faa43c416": { "Name": "immich_postgres", "EndpointID": "aa7aca87e353ce9f952d7add325225aba084fed40d60317bee3f9633fe890ce8", "MacAddress": "02:42:ac:1d:00:04", "IPv4Address": "172.29.0.4/16", "IPv6Address": "" }, "98aaec8b9d57a8b4a3174a7af2fec9d3d1efc70b57504d587891f6a14d0bcec2": { "Name": "immich_machine_learning", "EndpointID": "7aab8b30ca7e57fda1553979049955819c19cb8a73a19e307efe68eee7f9c64d", "MacAddress": "02:42:ac:1d:00:02", "IPv4Address": "172.29.0.2/16", "IPv6Address": "" }, "d0aeb03032e7a062b700e093f3897352ab13dbb7eb9c8386bec5fdc3d7c0d294": { "Name": "immich_server", "EndpointID": "f90ea0bd7ec783d521bcb7ea8c4d594c9fcb3f726ed32931622b0f7c938cdc54", "MacAddress": "02:42:ac:1d:00:05", "IPv4Address": "172.29.0.5/16", "IPv6Address": "" }, "f77d0c667aed808d9a643d776a3f6916b40668ed3e931096684addd1e51cad59": { "Name": "immich_redis", "EndpointID": "b5938243e43baf74e1e3580408c64d92c880b097e9832ac791760cf9863b6e01", "MacAddress": "02:42:ac:1d:00:03", "IPv4Address": "172.29.0.3/16", "IPv6Address": "" } }, "Options": {}, "Labels": { "com.docker.compose.config-hash": "261ce6b1aa11636c525c2f7b6d090301dd8b2838801d975c0e02b50f89308900", "com.docker.compose.network": "default", "com.docker.compose.project": "immich", "com.docker.compose.version": "" } } ] -
-
sudo docker exec -it immich_server nc -zv database 5432
CodeOCI runtime exec failed: exec failed: unable to start container process: exec: "nc": executable file not found in $PATH: unknownsudo docker exec -it immich_server bash -c 'cat < /dev/null > /dev/tcp/database/5432' && echo "Verbindung OK" || echo "Verbindung fehlgeschlagen"
-
littlenoob11, ich sehe gerade deinen Screenshot in #310.
Solche Image-Fehler unter Image, Lokal sehe ich auch bei mir - haufenweise. Das kommt wohl vor, wenn man einen Container über das Docker-GUI aktualisiert. Dann gibt es jedes Image mehrfach, nur eins davon ist ohne Fehler. Den Rest kann man wohl einfach löschen.
Hauptsache der Container selbst ist ohne Fehler. -
Sag mal, hast du die Firewall aktiv?
-
alter Mann den Wald vor lauter Bäumen nicht mehr gesehen...
Ich hatte die Firewall angepasst gehabt, aber wohl nicht korrekt.Danke dir!!
-
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!