Vaultwarden Container lässt sich nicht installieren

[Kachelkaiser]

Hallo,

ich habe den Container Manager auf Volume2 umgezogen. Dazu auch das Verzeichnis, in dem die Daten liegen (nicht Docker-Ordner)

Allerdings lässt sich der Container nicht mehr neu starten, geschweige denn komplett neu installieren.

Ich erhalte immer die Fehlermeldung

Failed to deploy a stack: compose up operation failed: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "/start.sh": stat /start.sh: no such file or directory: unknown

Außerdem mache ich ein Backup der Container mit diesem Skript

https://www.synology-forum.de/threa...-file-erstellen-als-backup.110444/post-897496

Diese wollte ich wieder als Stack inportieren. Auch das schlägt leider fehl.

Spoiler: YML

version: "3"
services:
  vaultwarden:
    cap_add:
      - AUDIT_WRITE
      - CHOWN
      - DAC_OVERRIDE
      - FOWNER
      - FSETID
      - KILL
      - MKNOD
      - NET_BIND_SERVICE
      - NET_RAW
      - SETFCAP
      - SETGID
      - SETPCAP
      - SETUID
      - SYS_CHROOT
    cap_drop:
      - AUDIT_CONTROL
      - BLOCK_SUSPEND
      - DAC_READ_SEARCH
      - IPC_LOCK
      - IPC_OWNER
      - LEASE
      - LINUX_IMMUTABLE
      - MAC_ADMIN
      - MAC_OVERRIDE
      - NET_ADMIN
      - NET_BROADCAST
      - SYSLOG
      - SYS_ADMIN
      - SYS_BOOT
      - SYS_MODULE
      - SYS_NICE
      - SYS_PACCT
      - SYS_PTRACE
      - SYS_RAWIO
      - SYS_RESOURCE
      - SYS_TIME
      - SYS_TTY_CONFIG
      - WAKE_ALARM
    command:
      - /start.sh
    container_name: vaultwarden
    environment:
      - TZ=Europe/Berlin
      - WEBSOCKET_ENABLED=true
      - ADMIN_TOKEN=XXXX
      - PUSH_INSTALLATION_ID=6fc8e688-02d9-41e2-90b4-b04300667099
      - PUSH_INSTALLATION_KEY=82tDfpCCfdLLcVTo9iZh
      - PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
      - ROCKET_PROFILE=release
      - ROCKET_ADDRESS=0.0.0.0
      - ROCKET_PORT=80
      - DEBIAN_FRONTEND=noninteractive
    hostname: vaultwarden
    image: vaultwarden/server:latest
    ipc: private
    labels:
      org.opencontainers.image.created: 2025-05-26T21:22:55+00:00
      org.opencontainers.image.description: 'Unofficial Bitwarden compatible server
        written in Rust - 1.34.1'
      org.opencontainers.image.documentation: https://github.com/dani-garcia/vaultwarden/wiki
      org.opencontainers.image.licenses: AGPL-3.0-only
      org.opencontainers.image.revision: 53f58b14d5626abfcefd52586ec9e78d067a2334
      org.opencontainers.image.source: https://github.com/dani-garcia/vaultwarden
      org.opencontainers.image.url: https://github.com/dani-garcia/vaultwarden
      org.opencontainers.image.version: 1.34.1
    logging:
      driver: db
      options: {}
    mac_address: 02:42:ac:11:00:05
    networks:
      - bridge
    ports:
      - 3012:3012/tcp
      - 5152:80/tcp
    restart: always
    stdin_open: true
    tty: true
    volumes:
      - /volume2/Bitwarden:/data
      - /volume2/Bitwarden/logs:/var/log/bitwarden.log
    working_dir: /
networks:
  bridge:
    external: true

Auch eine komplette Neuinstallation z.B. über Marius schlägt mit obiger Fehlermeldung fehl.

Hat jemand ne Idee dazu?

 

[mj084]

Lass das:

command: start.sh

mal weg - wo kommt das überhaupt her?

Und nimm mal deine InstallationsID und den Push-Key raus...
WebSocket muss auch nicht mehr angegeben werden - empfehle mal ein Update auf aktuellen Stand des Containers...

 

[Kachelkaiser]

das Problem bleibt bestehen. Das Kommando kam aus dem Backup, welches ich auch oben berlinkt habe

Ich habe jetzt mal testweise diesen stack benutzt. Auf der DS schlägt er fehl auf dem Raspi läuft er. Auf dem Raspi habe ich auch Docker Version 28.3.

Kann das damit zusammenhängen?

name: vaultwarden
services:
    server:
        container_name: vaultwarden
        ports:
            - 3012:3012
            - 5151:80
        environment:
            - ADMIN_TOKEN=test
        volumes:
            - /docker/vaultwarden:/data
        restart: always
        image: vaultwarden/server

 

[mj084]

Dann ist bei dir in Docker in DSM irgendwas zerschossen

Port wird nicht mehr 3012 benötigt, wenn du eh keine Umgebungsvariable für Websocket angibst...

Dein Push kann auch nicht funktionieren, da die Server fehlen...

 

[Esel08]

Also meiner ging :

YAML:

name: vaultwarden
services:
    server:
        container_name: vaultwarden
        ports:
            - 3012:3012
            - 3011:80
        volumes:
            - /volume1/docker/vaultwarden:/data
        environment:
            - ADMIN_TOKEN=.........
            - DISABLE_ADMIN_TOKEN=false
            - INVITATIONS_ALLOWED=false
            - WEBSOCKET_ENABLED=true
            - SIGNUPS_ALLOWE=true
            - TZ=Europe/Berlin
            - LOG_FILE=/var/log/bitwarden.log
        network_mode: bridge
        restart: always
        image: vaultwarden/server:latest

Grüße Jens

 

[Kachelkaiser]

hab ich gleich mal ausprobiert. Wieder die gleiche Fehlermeldung. Ich habe ja langsam den Container Manager selber im Verdacht.

Bloß den hatte ich eigentlich den ersten Fehlermeldungen auch neu installiert. Komisch.

 

[mj084]

Wenns in einer anderen Dockerumgebung klappt, kann es ja nur an deiner lokalen liegen
Ich würde mich auch immer an die offizielle Doku halten, und nicht bei Marius und Co. abschreiben, die pflegen nämlich die Anleitungen selten und das kann zu Problemen führen...

In der offiziellen Doku ist nix mehr von Websocket drin...

https://github.com/dani-garcia/vaultwarden/wiki/Using-Docker-Compose

 

[Kachelkaiser]

Ja ich Versuch Marius soweit es geht zu vermeiden. Deshalb habe ich die kleine compose direkt von vaultwarden versucht und das gleich ergebnis erhalten. Ich glaube der container manager ist kaputt

 

[Benares]

Gehen andere Pakete noch oder alles nicht mehr?

 

[haydibe]

Außerdem mache ich ein Backup der Container mit diesem Skript

https://www.synology-forum.de/threa...-file-erstellen-als-backup.110444/post-897496

Diese wollte ich wieder als Stack inportieren. Auch das schlägt leider fehl.

Hast Du das mit einer aktuellen Version von dem autocompose Image gemacht?
Neuere Versionen erzeugen nicht einfach eine 1:1 Compose-Datei Abbildung des aktuellen Containers, sondern schmeißen auch jede Menge unnützer Einstellungen weg.

Gerade wenn hier command, entrypoint und alle environments (also auch die, die über das Image kommen) übernommen werden, kann es zu Problemen führen, wenn neue Image Versionen Breaking Changes haben. Das wären dann aber auch Kandidaten, die bei Watchtower Updates knallen würden.

Kann das damit zusammenhängen?

Wird auf pi und DS das selbe Images (selber Repo:Tag mit identischem Digest?) verwendet? Wenn nicht, könnte es daran liegen.

Nicht das am Ende Dinge schief hängen, weil Docker Metadaten unter der Haube nicht mehr stimmen. Auf einem normalen Docker-Host ist bspw. die Empfehlung vor dem Umzug des data-root Verzeichnisses die Container vollständig zu entfernen, und darauf zu achten, dass der neue Ort dasselbe Dateisystem verwendet, damit weiterhin derselbe Storage Driver verwendet wird.

Ich könnte mir gut vorstellen, dass beim btrfs StorageDriver noch weitere Sonderlocken dazu kommen.

Update:
> Wird auf pi und DS das selbe Images (selber Repo:Tag mit identischem Digest?) verwendet? Wenn nicht, könnte es daran liegen.
*reusper* identischer Digest geht ja gar nicht, weil unterschiedliche CPU Architektur. Was aber geht: bei beiden jeweils das aktuellste Image hinter Repo:Tag zu ziehen.

 

[Mahoessen]

Ich glaube der container manager ist kaputt

Hi, den Container Manager schon mal gestoppt / neugestartet? vielleicht hängt dort noch irgendwas...

 

[ctrlaltdelete]

Ich habe es über den Aufgabenplaner installiert:
docker run -d --name=vaultwarden \
-p 3012:3012 \
-p 5151:80 \
-e ADMIN_TOKEN=geheim1234 \
-v /volume2/docker/vaultwarden:/data \
--restart always \
vaultwarden/server

 

[Kachelkaiser]

@Mahoessen jupp hab ich bereits gemacht, komplette Deinstallation

@ctrlaltdelete auch das habe ich bereits probiert, -> gleicher fehler. Irgendwas ist da faul

Vielleicht ist das ja ein Zeichen, mit Docker auf den Raspi umzuziehen

 

[Benares]

Du bist doch mit Docker auf ein anderes Volume umgezogen, oder?
Es gibt ja neben dem docker-Verzeichnis auch noch ein @Docker-Verzeichnis. Schau mal, ob es da vielleicht Unstimmigkeiten/Reste gibt.

root@DS1522:~# ls -als /volume1 | grep docker
     0 drwx--x---   1 root           root                 192 Jul  4 11:27 @docker
     0 drwxr-xr-x+  1 root           root                 250 Mar  5 12:36 docker

root@DS1522:~# mount | grep docker
/dev/mapper/cachedev_1 on /volume1/@docker type btrfs (rw,nodev,relatime,ssd,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50,block_group_cache_tree,syno_allocator,subvolid=256,subvol=/@syno)
/dev/mapper/cachedev_1 on /volume1/@docker/btrfs type btrfs (rw,nodev,relatime,ssd,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50,block_group_cache_tree,syno_allocator,subvolid=256,subvol=/@syno)
nsfs on /run/docker/netns/default type nsfs (rw)

 

[Kachelkaiser]

Hmm das kann natürlich sein. ich habe mal deine Befehle bei mir eingegeben, werde aber leider nicht schlau draus. Vielleicht kannst mir etwas auf die Sprünge helfen?

xxxxx@Speicherstadt:~$  ls -als /volume1 | grep docker
     0 drwx--x---   1 root            root                    0 Jul  2 10:27 @docker
     0 drwx--x---   1 root            root                  192 Jul  1 19:48 @docker_backup
xxxxx@Speicherstadt:~$  ls -als /volume2 | grep docker
0 drwx--x---   1 root         root          192 Jul 17 08:41 @docker
0 drwxrwxrwx+  1 root         root          252 Jul 18 10:54 docker
xxxxx@Speicherstadt:~$ mount | grep docker
/dev/mapper/cachedev_0 on /volume2/@docker type btrfs (rw,nodev,relatime,ssd,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50,block_group_cache_tree,syno_allocator,subvolid=256,subvol=/@syno)
/dev/mapper/cachedev_0 on /volume2/@docker/btrfs type btrfs (rw,nodev,relatime,ssd,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50,block_group_cache_tree,syno_allocator,subvolid=256,subvol=/@syno)
nsfs on /run/docker/netns/default type nsfs (rw)
shm on /volume2/@docker/containers/79c7062b36de1d189bfadcd0be389f3043e46b31d221cd01466f09cf69b1e7c9/mounts/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
nsfs on /run/docker/netns/6eb5fe9fb89e type nsfs (rw)
nsfs on /run/docker/netns/78b3c48219a7 type nsfs (rw)
/dev/mapper/cachedev_0 on /volume2/@appdata/ContainerManager/all_shares/docker type btrfs (rw,nodev,relatime,ssd,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50,block_group_cache_tree,syno_allocator,subvolid=658,subvol=/@syno/docker)
nsfs on /run/docker/netns/068f68ee9bba type nsfs (rw)
nsfs on /run/docker/netns/217fa55772cc type nsfs (rw)
nsfs on /run/docker/netns/50948f8e716b type nsfs (rw)
nsfs on /run/docker/netns/73cb2a262f09 type nsfs (rw)

 

[tproko]

umzuziehen

Habe mal Testweise versucht, eine DB auf dem RaspPI laufen zulassen. Die CPU limitiert da schnell ;-)
Und wenn du dann DB + Vaultwarden Webanwendung laufen lassen willst, dann wirst du viel Geduld brauchen.

Da ist dann die DS quasi super schnell, und die ist schon ne Schnecke bezüglich Virtualisierung.

 

[Kachelkaiser]

Derzeit läuft der Vaultwarden Container auf dem Raspi als Backup sozusagen und die Geschwindigkeit ist mehr als ausreichend. Der Container verwendet eine SQLite-DB.

Trotzdem würde ich gerne wieder einen funktionierenden Container Manager auf der DS haben

Ich überlege gerade, den Inhalt des Docker Ordners zu kopieren und dann die Container Manager so zu deinstallieren, dass der Docker Ordner gelöscht und bei Neuinstallation wieder neu erstellt wird....

 

[Benares]

Mmh, sieht m.E. eigentlich vernünftig aus. Ist halt nur etwas verwirrend, da es auf volume1 noch Reste vom alten Docker gibt.
Laufen denn andere Container sauber?

 

[Kachelkaiser]

ja andere laufen (mittlerweile) wieder sauber. Ein paar musste ich auch neu aufsetzen, weil sie sich geweigert hatten. Aber solche Probleme wie mit vaultwarden hatte ich keine.

 

[mj084]

Ich habe es über den Aufgabenplaner installiert:
docker run -d --name=vaultwarden \
-p 3012:3012 \
-p 5151:80 \
-e ADMIN_TOKEN=geheim1234 \
-v /volume2/docker/vaultwarden:/data \
--restart always \
vaultwarden/server

Aus welcher Doku nimmst du den TCP Port 3012:3012 denn her?