Portainer (limited) in Kombination mit openmediavault und immich

RolloMollo

Cadet 4th Year
Registriert
Apr. 2020
Beiträge
67
Hallo.

Ich hatte Portainer auf OMV installiert. Darauf lief dann im Stack immich. Soweit alles wunderbar.
Dann hatte ich in der Vergangenheit (kann mich an die Motivation nicht erinnern) Portainer neu installiert. Asche auf mein Haupt. Jetzt kommt ich zwar in Portainer rein jedoch hab ich nur "limited" Zugriff. Entsprechend kann ich auf den Stack nicht mehr zugreifen und somit immich updaten.
Ich hab mich dann mal via CLI zur compose.yml durchgeklickt. Wenn ich nun docker compose pull ausführen möchte, erhalte ich die Fehlermeldung "invalid spec: :/var/lib/postgresql/data: empty sections between colons". Entsprechend wird der Befehl nicht ausgeführt.
Jemand eine Ahnung wie ich vorgehen soll?

Ok ich vermute es hängt damit zusammen:
https://github.com/immich-app/immich/releases/tag/v1.102.0
Meine env sieht so aus:
"DB_DATA_LOCATION=/srv/dev-disk-by-uuid-22f7f90f-63e2-4aae-9125-ba7f790e50de/docker_data"

Im Link steht
"
Do not use a directory under /mnt for the postgres location if you are using WSL.
Generally (on all operating systems) we recommend against using a network share for your database location. This is bound to break and cause all sorts of weird issues.
"

Dann ist wohl die entscheidende Frage wie ich das gefixt kriege ohne meine Daten zu verlieren...
 
Zuletzt bearbeitet:
Die Fehlermeldung sowie die Hinweise aus dem Immich-Release-Note deuten darauf hin, dass es ein Problem mit der Definition des Datenbankverzeichnisses (DB_DATA_LOCATION) und dessen Integration in die docker-compose.yml

Die Fehlermeldung "invalid spec: :/var/lib/postgresql/data: empty sections between colons" deutet darauf hin, dass ein Fehler in der docker-compose.yml in der Definition des Volumes für die PostgreSQL-Datenbank vorliegt. Es fehlt wahrscheinlich der lokale Pfad vor dem Doppelpunkt.

Öffne die docker-compose.yml und überprüfe die Zeile, in der das Volume für PostgreSQL definiert ist.

Beispiel für den fehlerhaften Eintrag - musst du schauen, wie das drin steht...
volumes: - :/var/lib/postgresql/data

Wahrscheinlich richtig:
volumes: - ${DB_DATA_LOCATION}:/var/lib/postgresql/data

Achte darauf, dass DB_DATA_LOCATION in deiner .env korrekt definiert ist und einen absoluten Pfad angibt:
  • DB_DATA_LOCATION=/srv/dev-disk-by-uuid-22f7f90f-63e2-4aae-9125-ba7f790e50de/docker_data

Oder folgendes laut Release-Note ... da wird davor gewarnt, Netzwerkfreigaben oder WSL-spezifische Verzeichnisse für PostgreSQL zu verwenden. Diese könnten zu Problemen führen, insbesondere bei der Performance und Datenintegrität. Da muss ich aber noch schauen, wie das geht
Ergänzung ()

Falls das aktuelle Datenbankverzeichnis auf einem Netzwerk-Laufwerk (/mnt/...) oder einer WSL-Partition liegt verschiebe die Datenbankdaten auf einen lokalen Speicherort.

mkdir -p /srv/postgres_data
mv /srv/dev-disk-by-uuid-22f7f90f-63e2-4aae-9125-ba7f790e50de/docker_data /srv/postgres_data

Aktualisiere die .env:
DB_DATA_LOCATION=/srv/postgres_data

Passe die docker-compose.yml entsprechend an.

Es kann aber auch sein, dass wenn Portainer neu installiert wurde, hat es keinen Zugriff mehr auf bestehende Container/Stacks, da die Zuordnung verloren gegangen ist.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: TheBeastMaster
Danke.
Ich poste dir mal beide Dateien.
Wenn ich mich nicht irre sollte die Konfiguration aber richtig sein oder?

stack
Code:
UPLOAD_LOCATION=/srv/dev-disk-by-uuid-22f7f90f-63e2-4aae-9125-ba7f790e50de/pictures
DB_DATA_LOCATION=/srv/dev-disk-by-uuid-22f7f90f-63e2-4aae-9125-ba7f790e50de/docker_data
IMMICH_VERSION=release
DB_PASSWORD=password
DB_USERNAME=postgres
DB_DATABASE_NAME=immich

compose
Code:
name: immich
services:
  immich-server:
     container_name: immich_server
     image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release?
     volumes:
       - #{UPLOAD_LOCATION}:/usr/src/app/upload
       - /etc/localtime:/etc/localtime:ro
    env_file:
      - stack.env
    ports:
      - 2283:3001
    depends_on:
      - redis
      - database
    restart: always

immich-machine-learning:
  container_name: immich_machine_learning
  image: ghcr.io/immich-app/immich-machine-learning:#{IMMICH_VERSION:-release?
  volumes:
    - model-cache:/cache
  env_file:
    - stack.env
  restart: always
 
redis:
  container_name: immich_redis
  image: registry.hub.docker.com/library/redis:6.2-alpine@sha256:84882e87b54734154586e5f8abd4dce69fe7311315e2fc6d67c29614c8de2672
  restart: always

database:
  container_name: immich_postgres
  image: registry.hub.docker.com/tensorchord/pgvecto-rs:pg14-v0.2.00sha256: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
    restart: always
    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"

volumes:
  model-cache:
 
Zuletzt bearbeitet:
Schlagt mich nicht aber ich würde sagen die Umgebungsvariablen (#{...}) sind falsch definiert. Docker Compose erwartet entweder ${VARIABLE_NAME} für Variablen aus der .env-Datei oder direkte Werte. #{...} ist keine gültige Syntax.

Der Eintrag env_file verweist auf stack.env. Stelle sicher, dass sich diese Datei im gleichen Verzeichnis wie die docker-compose.yml befindet. Falls sie in einem anderen Pfad liegt, passe die Referenz an.

Die Fehler in der volumes-Definition könnten zu Problemen führen:
  • Stelle dort sicher, dass die Pfade in den Volumes existieren, insbesondere:
    • /srv/dev-disk-by-uuid-22f7f90f-63e2-4aae-9125-ba7f790e50de/docker_data
    • /srv/dev-disk-by-uuid-22f7f90f-63e2-4aae-9125-ba7f790e50de/pictures


Und kann sein, dass in der aktuellen compose.yml die Anführungszeichen im command falsch gesetzt sind?

Check mal was "docker-compose config" sagt. Die ursprüngliche Datei hat m.E. Syntaxfehler (falsches Anführungszeichen, inkorrekte Platzierung).

Aber der Test sollte dies ja wiedergeben:
docker compose pull
docker compose up -d
 
  • Gefällt mir
Reaktionen: ksk23
Stimme dem Vorredner generell zu.
Darüber hinaus aber: Das "stack.env" war das, was Portainer "magisch" aus seinem Datenbestand zugesteuert hätte: Wenn du das verloren hast, wirst du dessen Inhalte nachbauen müssen..

Dort waren dann auch im Zweifel die DB-passworte hinterlegt, wird nicht gerade rosig wenn du das alles nichtmehr kennst fürchte ich.
 
Hallo.

Erstmal herzlichen Dank für den Support.
Ehrlicherweise hab ich die yml als auch stack via OCR von CLI abgeschrieben. Ich versuche gerade die Datei zu kopieren, sodass ihr ein sauberes Bild habt.
Password zur Database habe ich noch alle. Ich habe das nur im Post ausgebaut, da nicht relevant.

Ich bin auch gerne für eine andere Lösung offen.
Kann man nicht vielleicht irgendwie in der neuen Portainer Instanz den Stack neu aufsetzen? Mit gleiche Pfaden etc damit alle erhalten bleibt natürlich.

Melde mich (hoffentlich) gleich mit den Dateien in diesem Post.

compose (NEU)
Code:
# WARNING: Make sure to use the docker-compose.yml of the current release:
#
# https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
#
# The compose file on main may not be compatible with the latest release.
#

name: immich

services:
  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    volumes:
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
    env_file:
      - stack.env
    ports:
      - 2283:3001
    depends_on:
      - redis
      - database
    restart: always



  immich-machine-learning:
    container_name: immich_machine_learning
    # For hardware acceleration, add one of -[armnn, cuda, openvino] to the image tag.
    # Example tag: ${IMMICH_VERSION:-release}-cuda
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    # extends: # uncomment this section for hardware acceleration - see https://immich.app/docs/features/ml-hardware-acceleration
    #   file: hwaccel.ml.yml
    #   service: cpu # set to one of [armnn, cuda, openvino, openvino-wsl] for accelerated inference - use the `-wsl` version for WSL2 where applicable
    volumes:
      - model-cache:/cache
    env_file:
      - stack.env
    restart: always

  redis:
    container_name: immich_redis
    image: registry.hub.docker.com/library/redis:6.2-alpine@sha256:84882e87b54734154586e5f8abd4dce69fe7311315e2fc6d67c29614c8de2672
    restart: always

  database:
    container_name: immich_postgres
    image: registry.hub.docker.com/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
    restart: always
    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",>

volumes:
  model-cache:

stack (NEU)
Code:
UPLOAD_LOCATION=/srv/dev-disk-by-uuid-22f7f90f-63e2-4aae-9125-ba7f790e50de/pictures
DB_DATA_LOCATION=/srv/dev-disk-by-uuid-22f7f90f-63e2-4aae-9125-ba7f790e50de/docker_data
IMMICH_VERSION=release
DB_PASSWORD=XXXX
DB_USERNAME=postgres
DB_DATABASE_NAME=immich
Ergänzung ()

wertzuiop123 schrieb:
Der Eintrag env_file verweist auf stack.env. Stelle sicher, dass sich diese Datei im gleichen Verzeichnis wie die docker-compose.yml befindet. Falls sie in einem anderen Pfad liegt, passe die Referenz an.
Ist im gleichen Ordner.
 
Zuletzt bearbeitet:
@ksk23 Ich habe Zugriff auf den Server und kann "docker" in CLI ausführen, ja.
Kannst du mir sagen wie ich die DB backupe? Bin da nicht so bewandert.
Ergänzung ()

wertzuiop123 schrieb:
Die Fehler in der volumes-Definition könnten zu Problemen führen:
  • Stelle dort sicher, dass die Pfade in den Volumes existieren, insbesondere:
    • /srv/dev-disk-by-uuid-22f7f90f-63e2-4aae-9125-ba7f790e50de/docker_data
    • /srv/dev-disk-by-uuid-22f7f90f-63e2-4aae-9125-ba7f790e50de/pictures
Ich glaube auch irgendwo hier in OMV liegt ggf. ein Fehler begraben.
Ich bin einfach schusselig und hab damals warum auch immer Portainer neu aufgesetzt. Ziemlicher Unfug. Ich kann aber leider nichts daran ändern.
Ergänzung ()

wertzuiop123 schrieb:
Check mal was "docker-compose config" sagt. Die ursprüngliche Datei hat m.E. Syntaxfehler (falsches Anführungszeichen, inkorrekte Platzierung).
Code:
root@openmediavault:/srv/dev-disk-by-uuid-d2c58590-93d7-4346-af7a-5c7856a3738f/docker/volumes/portainer_data/_data/compose/2# docker-compose config
WARN[0000] The "UPLOAD_LOCATION" variable is not set. Defaulting to a blank string.
WARN[0000] The "DB_PASSWORD" variable is not set. Defaulting to a blank string.
WARN[0000] The "DB_USERNAME" variable is not set. Defaulting to a blank string.
WARN[0000] The "DB_DATABASE_NAME" variable is not set. Defaulting to a blank string.
WARN[0000] The "DB_DATA_LOCATION" variable is not set. Defaulting to a blank string.
invalid spec: :/var/lib/postgresql/data: empty section between colons
Ergänzung ()

wertzuiop123 schrieb:
mkdir -p /srv/postgres_data
mv /srv/dev-disk-by-uuid-22f7f90f-63e2-4aae-9125-ba7f790e50de/docker_data /srv/postgres_data

Aktualisiere die .env:
DB_DATA_LOCATION=/srv/postgres_data

Passe die docker-compose.yml entsprechend an.
Ich hab jetzt diesen Befehl mal benutzt. Dadurch sollte ich eine Kopie behalten oder?
Code:
cp -r /srv/dev-disk-by-uuid-22f7f90f-63e2-4aae-9125-ba7f790e50de/docker_data /srv/postgres_data
 

Anhänge

  • Bildschirmfoto 2025-01-14 um 12.21.09.png
    Bildschirmfoto 2025-01-14 um 12.21.09.png
    84,7 KB · Aufrufe: 23
  • Bildschirmfoto 2025-01-14 um 12.21.15.png
    Bildschirmfoto 2025-01-14 um 12.21.15.png
    62,3 KB · Aufrufe: 20
Zuletzt bearbeitet:
keinen Kollegen zur Hand, der mal Sysadmin gemacht haT? Das Risiko des Datenverlustes ist nicht gering, möchte dich da auch nicht in den Ruin anleiten.

Bei Datenbanken ist das so, dass du lieber eineb "dump" machen solltest, und nicht einfach die "Platte" wegsichern. Schau mal hier rein: https://gist.github.com/itSQualL/dc17356ba05ce3ef881ba5ff1bc4dfbc
Du musst die Beispiele entsprechend der von dir verwendeten schemanamen anpassen.

Wenn du den Dump erstellt hast, könntest du den alten stack erstmal runterfahren (stop).
Dann mit dem Aufbau des neuen Stacks beginnen; Wenn der rudimentär steht, beschreibt der guide, wie du den vorher erstellten dump dort wieder einspielen kannst.

Pass auf beim hantieren mit dem pgdump/restore: überschreibe nicht deine alte, noch fuktionale Datenbank!
 
  • Gefällt mir
Reaktionen: RolloMollo und wertzuiop123
Zurück
Oben