starred/vaultwarden
1
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-04-25 17:25:57 +03:00
Code Issues 39 Projects Releases 5 Packages Wiki Activity

[GH-ISSUE #1815] server:1.22.1-alpine not starting #1067

New issue
Closed
opened 2026-03-03 02:05:58 +03:00 by kerem · 8 comments
kerem commented 2026-03-03 02:05:58 +03:00
Owner
Copy link

Originally created by @vincentchu37 on GitHub (Jul 1, 2021).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1815

Subject of the issue

Upgrading to server:1.22.1-alpine from server:1.21.0-alpine unable to start

Deployment environment

Docker in Docker Swarm

  • vaultwarden version: 1.22.1

  • Install method: Docker in Docker Swarm

Steps to reproduce.

Bumped docker image version in docker-compose.yml ran docker stack deploy. Unable to start with this error.

bitwarden_bitwarden.1.nc55g1zd3bmc@otter    | /--------------------------------------------------------------------\
bitwarden_bitwarden.1.2gmo8v0f67md@weasel    | 
bitwarden_bitwarden.1.nc55g1zd3bmc@otter    | |                        Starting Vaultwarden                        |
bitwarden_bitwarden.1.nc55g1zd3bmc@otter    | |                           Version 1.22.1                           |
bitwarden_bitwarden.1.nc55g1zd3bmc@otter    | |--------------------------------------------------------------------|
bitwarden_bitwarden.1.nc55g1zd3bmc@otter    | | This is an *unofficial* Bitwarden implementation, DO NOT use the   |
bitwarden_bitwarden.1.nc55g1zd3bmc@otter    | | official channels to report bugs/features, regardless of client.   |
bitwarden_bitwarden.1.nc55g1zd3bmc@otter    | | Send usage/configuration questions or feature requests to:         |
bitwarden_bitwarden.1.nc55g1zd3bmc@otter    | |   https://vaultwarden.discourse.group/                             |
bitwarden_bitwarden.1.nc55g1zd3bmc@otter    | | Report suspected bugs/issues in the software itself at:            |
bitwarden_bitwarden.1.nc55g1zd3bmc@otter    | |   https://github.com/dani-garcia/vaultwarden/issues/new            |
bitwarden_bitwarden.1.nc55g1zd3bmc@otter    | \--------------------------------------------------------------------/
bitwarden_bitwarden.1.nc55g1zd3bmc@otter    | 
bitwarden_bitwarden.1.nc55g1zd3bmc@otter    | [INFO] No .env file found.
bitwarden_bitwarden.1.nc55g1zd3bmc@otter    | 
bitwarden_bitwarden.1.nc55g1zd3bmc@otter    | [2021-07-01 19:38:15.850][panic][ERROR] thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Serde.
bitwarden_bitwarden.1.nc55g1zd3bmc@otter    | [CAUSE] Error("missing field `id`", line: 1, column: 2420)': src/main.rs:58
bitwarden_bitwarden.1.nc55g1zd3bmc@otter    |    0: <unknown>
bitwarden_bitwarden.1.nc55g1zd3bmc@otter    |    1: <unknown>
bitwarden_bitwarden.1.nc55g1zd3bmc@otter    |    2: <unknown>

Reverting back to server:1.21.0-alpine it starts fine with no warnings or errors.

Originally created by @vincentchu37 on GitHub (Jul 1, 2021). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1815 ### Subject of the issue Upgrading to server:1.22.1-alpine from server:1.21.0-alpine unable to start ### Deployment environment Docker in Docker Swarm * vaultwarden version: 1.22.1 * Install method: Docker in Docker Swarm ### Steps to reproduce. Bumped docker image version in docker-compose.yml ran docker stack deploy. Unable to start with this error. ``` bitwarden_bitwarden.1.nc55g1zd3bmc@otter | /--------------------------------------------------------------------\ bitwarden_bitwarden.1.2gmo8v0f67md@weasel | bitwarden_bitwarden.1.nc55g1zd3bmc@otter | | Starting Vaultwarden | bitwarden_bitwarden.1.nc55g1zd3bmc@otter | | Version 1.22.1 | bitwarden_bitwarden.1.nc55g1zd3bmc@otter | |--------------------------------------------------------------------| bitwarden_bitwarden.1.nc55g1zd3bmc@otter | | This is an *unofficial* Bitwarden implementation, DO NOT use the | bitwarden_bitwarden.1.nc55g1zd3bmc@otter | | official channels to report bugs/features, regardless of client. | bitwarden_bitwarden.1.nc55g1zd3bmc@otter | | Send usage/configuration questions or feature requests to: | bitwarden_bitwarden.1.nc55g1zd3bmc@otter | | https://vaultwarden.discourse.group/ | bitwarden_bitwarden.1.nc55g1zd3bmc@otter | | Report suspected bugs/issues in the software itself at: | bitwarden_bitwarden.1.nc55g1zd3bmc@otter | | https://github.com/dani-garcia/vaultwarden/issues/new | bitwarden_bitwarden.1.nc55g1zd3bmc@otter | \--------------------------------------------------------------------/ bitwarden_bitwarden.1.nc55g1zd3bmc@otter | bitwarden_bitwarden.1.nc55g1zd3bmc@otter | [INFO] No .env file found. bitwarden_bitwarden.1.nc55g1zd3bmc@otter | bitwarden_bitwarden.1.nc55g1zd3bmc@otter | [2021-07-01 19:38:15.850][panic][ERROR] thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Serde. bitwarden_bitwarden.1.nc55g1zd3bmc@otter | [CAUSE] Error("missing field `id`", line: 1, column: 2420)': src/main.rs:58 bitwarden_bitwarden.1.nc55g1zd3bmc@otter | 0: <unknown> bitwarden_bitwarden.1.nc55g1zd3bmc@otter | 1: <unknown> bitwarden_bitwarden.1.nc55g1zd3bmc@otter | 2: <unknown> ``` Reverting back to server:1.21.0-alpine it starts fine with no warnings or errors.
kerem 2026-03-03 02:05:58 +03:00
kerem commented 2026-03-03 02:05:59 +03:00
Author
Owner
Copy link

@BlackDex commented on GitHub (Jul 1, 2021):

Seems to be something with the webauthn migration.
Not sure what it could be to cause this.

<!-- gh-comment-id:872600904 --> @BlackDex commented on GitHub (Jul 1, 2021): Seems to be something with the webauthn migration. Not sure what it could be to cause this.
kerem commented 2026-03-03 02:05:59 +03:00
Author
Owner
Copy link

@vincentchu37 commented on GitHub (Jul 1, 2021):

I have another instance that uses docker (non-swarm) that i just upgraded to server:1.22.1-alpine and it started up fine. I'm not sure if this is relevant, but

Here are the two docker-composes

Non-Working (Swarm)

version: "3.4"
services:
  bitwarden:
    image: vaultwarden/server:1.22.1-alpine
    volumes:
      - type: bind
        source: /mnt/app/bitwarden
        target: /data
    environment:
      http_proxy: http://proxy.example.com
      https_proxy: http://proxy.example.com
      no_proxy: localhost,.example.com,.mgmt
      SMTP_HOST: mail.example.com
      SMTP_FROM: adm@example.com
      SMTP_SSL: "false"
      DOMAIN: https://example.com
    ports:
      - published: 2814
        target: 80

Working (Non-Swarm)

version: "3.7"
services:
  bitwarden:
    container_name: bitwarden
    image: vaultwarden/server:alpine
    volumes:
      - type: bind
        source: /home/ubuntu/docker/bitwarden
        target: /data
    restart: always
    environment:
      ADMIN_TOKEN: ${ADMIN_TOKEN}
      SMTP_HOST: mail.mx.example.com
      SMTP_FROM: bitwarden@mx.example.com
      SMTP_USERNAME: mail@mx.example.com
      SMTP_PASSWORD: ${EMAIL_PASSWORD}
      DOMAIN: https://bitwarden.example.com
      SIGNUPS_ALLOWED: "false"
    ports:
      - published: 4241
        target: 80
    networks:
      static-network:
        ipv4_address: 10.41.1.3

networks:
  static-network:
    ipam:
      config:
        - subnet: 10.41.1.0/24
<!-- gh-comment-id:872614838 --> @vincentchu37 commented on GitHub (Jul 1, 2021): I have another instance that uses docker (non-swarm) that i just upgraded to server:1.22.1-alpine and it started up fine. I'm not sure if this is relevant, but Here are the two docker-composes Non-Working (Swarm) ``` version: "3.4" services: bitwarden: image: vaultwarden/server:1.22.1-alpine volumes: - type: bind source: /mnt/app/bitwarden target: /data environment: http_proxy: http://proxy.example.com https_proxy: http://proxy.example.com no_proxy: localhost,.example.com,.mgmt SMTP_HOST: mail.example.com SMTP_FROM: adm@example.com SMTP_SSL: "false" DOMAIN: https://example.com ports: - published: 2814 target: 80 ``` Working (Non-Swarm) ``` version: "3.7" services: bitwarden: container_name: bitwarden image: vaultwarden/server:alpine volumes: - type: bind source: /home/ubuntu/docker/bitwarden target: /data restart: always environment: ADMIN_TOKEN: ${ADMIN_TOKEN} SMTP_HOST: mail.mx.example.com SMTP_FROM: bitwarden@mx.example.com SMTP_USERNAME: mail@mx.example.com SMTP_PASSWORD: ${EMAIL_PASSWORD} DOMAIN: https://bitwarden.example.com SIGNUPS_ALLOWED: "false" ports: - published: 4241 target: 80 networks: static-network: ipv4_address: 10.41.1.3 networks: static-network: ipam: config: - subnet: 10.41.1.0/24 ```
kerem commented 2026-03-03 02:05:59 +03:00
Author
Owner
Copy link

@BlackDex commented on GitHub (Jul 2, 2021):

It has something to do with the two factor authentication. So something in the database of there falling server is causing it to fall

<!-- gh-comment-id:872739578 --> @BlackDex commented on GitHub (Jul 2, 2021): It has something to do with the two factor authentication. So something in the database of there falling server is causing it to fall
kerem commented 2026-03-03 02:05:59 +03:00
Author
Owner
Copy link

@NorthernLightsDevel commented on GitHub (Jul 5, 2021):

I have the same issue with Kubernetes deployment, works if I set vaultwarden/server:1.21.0 for 1.22.x it seems to freeze somewhere between trying to load the .env file and launching Rocket.

deployment file:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: bitwarden-rs
  name: bitwarden-rs
spec:
  selector:
    matchLabels:
      app: bitwarden-rs
      tier: server
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: bitwarden-rs
        tier: server
    spec:
      containers:
      - env:
        - name: SMTP_HOST
          valueFrom:
            secretKeyRef:
              key: smtp-server
              name: mail-settings
        - name: SMTP_USERNAME
          valueFrom:
            secretKeyRef:
              key: apikey
              name: mail-settings
        - name: SMTP_PASSWORD
          valueFrom:
            secretKeyRef:
              key: password
              name: mail-settings
        envFrom:
        - configMapRef:
            name: bitwarden-rs
        image: vaultwarden/server:latest
        imagePullPolicy: Always
        name: bitwarden-rs
        ports:
        - containerPort: 80
          protocol: TCP
        resources:
          limits:
            cpu: "4"
            memory: 2Gi
          requests:
            cpu: "2"
            memory: 1Gi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /data
          name: bitwarden-rs-data
      restartPolicy: Always
      volumes:
      - name: bitwarden-rs-data
        persistentVolumeClaim:
          claimName: bitwarden-rs-data

Config-map

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    app: bitwarden-rs
  name: bitwarden-rs
data:
  DOMAIN: https://passwords.example.com
  SIGNUPS_ALLOWED: "false"
  SMTP_FROM: bitwarden@example.com
  SMTP_PORT: "587"
  SMTP_SSL: "true"
<!-- gh-comment-id:873924768 --> @NorthernLightsDevel commented on GitHub (Jul 5, 2021): I have the same issue with Kubernetes deployment, works if I set vaultwarden/server:1.21.0 for 1.22.x it seems to freeze somewhere between trying to load the .env file and launching Rocket. deployment file: ``` yaml apiVersion: apps/v1 kind: Deployment metadata: labels: app: bitwarden-rs name: bitwarden-rs spec: selector: matchLabels: app: bitwarden-rs tier: server strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 1 type: RollingUpdate template: metadata: labels: app: bitwarden-rs tier: server spec: containers: - env: - name: SMTP_HOST valueFrom: secretKeyRef: key: smtp-server name: mail-settings - name: SMTP_USERNAME valueFrom: secretKeyRef: key: apikey name: mail-settings - name: SMTP_PASSWORD valueFrom: secretKeyRef: key: password name: mail-settings envFrom: - configMapRef: name: bitwarden-rs image: vaultwarden/server:latest imagePullPolicy: Always name: bitwarden-rs ports: - containerPort: 80 protocol: TCP resources: limits: cpu: "4" memory: 2Gi requests: cpu: "2" memory: 1Gi terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumeMounts: - mountPath: /data name: bitwarden-rs-data restartPolicy: Always volumes: - name: bitwarden-rs-data persistentVolumeClaim: claimName: bitwarden-rs-data ``` Config-map ``` yaml apiVersion: v1 kind: ConfigMap metadata: labels: app: bitwarden-rs name: bitwarden-rs data: DOMAIN: https://passwords.example.com SIGNUPS_ALLOWED: "false" SMTP_FROM: bitwarden@example.com SMTP_PORT: "587" SMTP_SSL: "true" ```
kerem commented 2026-03-03 02:05:59 +03:00
Author
Owner
Copy link

@BlackDex commented on GitHub (Jul 5, 2021):

@vincentchu37, i think it has to do with some data stored within the database.
Within the twofactor table, there is a field called data which holds a json including data of your key, including the id.
For some reason that id field is missing from the json string, which is causing an issue during the migration to webauthn.
If you are able to see which user has this id field missing within the json data within the data field in the database, then i would suggest to contact that user, remove his 2FA tokens via the /admin/users/overview page, and let him re-register his tokens.

You could first remove his 2FA tokens, update Vaultwarden, and then let that user re-register his tokens, that way the user goes through the new webauthn path already instead of it being migrated.

<!-- gh-comment-id:874304283 --> @BlackDex commented on GitHub (Jul 5, 2021): @vincentchu37, i think it has to do with some data stored within the database. Within the `twofactor` table, there is a field called `data` which holds a json including data of your key, including the `id`. For some reason that `id` field is missing from the json string, which is causing an issue during the migration to webauthn. If you are able to see which user has this `id` field missing within the json data within the `data` field in the database, then i would suggest to contact that user, remove his 2FA tokens via the `/admin/users/overview` page, and let him re-register his tokens. You could first remove his 2FA tokens, update Vaultwarden, and then let that user re-register his tokens, that way the user goes through the new webauthn path already instead of it being migrated.
kerem commented 2026-03-03 02:05:59 +03:00
Author
Owner
Copy link

@vincentchu37 commented on GitHub (Jul 6, 2021):

@BlackDex

Looking at the data field in the twofactor table, I don't even see any keys named id.

Here is all the json I dumped from the twofactor table. I have removed a lot of data, but the structure is here

{"appId":"https://bitwarden.test.example.com/app-id.json","challenge":"=","timestamp":"2019-08-12T21:00:13.006136080Z"}

[{"keyHandle":[1],"pubKey":[1],"attestationCert":[1]}]

{"appId":"https://test-bitwarden.example.com/app-id.json","challenge":"/=","timestamp":"2020-05-04T15:01:17.027033134Z"}

{"email":"user@example.com","last_token":null,"token_sent":1,"attempts":0}
<!-- gh-comment-id:875063213 --> @vincentchu37 commented on GitHub (Jul 6, 2021): @BlackDex Looking at the `data` field in the `twofactor` table, I don't even see any keys named `id`. Here is all the json I dumped from the twofactor table. I have removed a lot of data, but the structure is here ``` {"appId":"https://bitwarden.test.example.com/app-id.json","challenge":"=","timestamp":"2019-08-12T21:00:13.006136080Z"} [{"keyHandle":[1],"pubKey":[1],"attestationCert":[1]}] {"appId":"https://test-bitwarden.example.com/app-id.json","challenge":"/=","timestamp":"2020-05-04T15:01:17.027033134Z"} {"email":"user@example.com","last_token":null,"token_sent":1,"attempts":0} ```
kerem commented 2026-03-03 02:05:59 +03:00
Author
Owner
Copy link

@vincentchu37 commented on GitHub (Jul 23, 2021):

I managed to workaround this by deleting all user's yubikeys.

<!-- gh-comment-id:885729059 --> @vincentchu37 commented on GitHub (Jul 23, 2021): I managed to workaround this by deleting all user's yubikeys.
kerem commented 2026-03-03 02:05:59 +03:00
Author
Owner
Copy link

@BlackDex commented on GitHub (Jul 26, 2021):

@BlackDex

Looking at the data field in the twofactor table, I don't even see any keys named id.

Here is all the json I dumped from the twofactor table. I have removed a lot of data, but the structure is here

{"appId":"https://bitwarden.test.example.com/app-id.json","challenge":"=","timestamp":"2019-08-12T21:00:13.006136080Z"}

[{"keyHandle":[1],"pubKey":[1],"attestationCert":[1]}]

{"appId":"https://test-bitwarden.example.com/app-id.json","challenge":"/=","timestamp":"2020-05-04T15:01:17.027033134Z"}

{"email":"user@example.com","last_token":null,"token_sent":1,"attempts":0}

Strange, as i do not see any former U2F token there in your example.
That work-around is a solution indeed, but it is still strange.

I'm at least glad you could update. Also, there has been released a new version yesterday/today which also has some fixes regarding WebAuthn.

<!-- gh-comment-id:886510834 --> @BlackDex commented on GitHub (Jul 26, 2021): > @BlackDex > > Looking at the `data` field in the `twofactor` table, I don't even see any keys named `id`. > > Here is all the json I dumped from the twofactor table. I have removed a lot of data, but the structure is here > > ``` > {"appId":"https://bitwarden.test.example.com/app-id.json","challenge":"=","timestamp":"2019-08-12T21:00:13.006136080Z"} > > [{"keyHandle":[1],"pubKey":[1],"attestationCert":[1]}] > > {"appId":"https://test-bitwarden.example.com/app-id.json","challenge":"/=","timestamp":"2020-05-04T15:01:17.027033134Z"} > > {"email":"user@example.com","last_token":null,"token_sent":1,"attempts":0} > ``` Strange, as i do not see any former U2F token there in your example. That work-around is a solution indeed, but it is still strange. I'm at least glad you could update. Also, there has been released a new version yesterday/today which also has some fixes regarding WebAuthn.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
revert-7033-patch-1
cached-config-operations
test_dylint
1.35.7
1.35.6
1.35.5
1.35.4
1.35.3
1.35.2
1.35.1
1.35.0
1.34.3
1.34.2
1.34.1
1.34.0
1.33.2
1.33.1
1.33.0
1.32.7
1.32.6
1.32.5
1.32.4
1.32.3
1.32.2
1.32.1
1.32.0
1.31.0
1.30.5
1.30.4
1.30.3
1.30.2
1.30.1
1.30.0
1.29.2
1.29.1
1.29.0
1.28.1
1.28.0
1.27.0
1.26.0
1.25.2
1.25.1
1.25.0
1.24.0
1.23.1
1.23.0
1.22.2
1.22.1
1.22.0
1.21.0
1.20.0
1.19.0
1.18.0
1.17.0
1.16.3
1.16.2
1.16.1
1.16.0
1.15.1
1.15.0
1.14.2
1.14.1
1.14
1.13.1
1.13.0
1.12.0
1.11.0
1.10.0
1.9.1
1.9.0
1.8.0
1.7.0
1.6.1
1.6.0
1.5.0
1.4.0
1.3.0
1.2.0
1.1.0
1.0.0
0.13.0
0.12.0
0.11.0
0.10.0
0.9.0
Labels
Clear labels   
SSO

   
Third party

   
better for forum

   
bug

   
bug

   
documentation

   
duplicate

   
enhancement

   
future Vault

   
future Vault

   
future Vault

   
good first issue

   
help wanted

   
low priority

   
notes

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
troubleshooting

   
wontfix
No labels
SSO
Third party
better for forum
bug
bug
documentation
duplicate
enhancement
future Vault
future Vault
future Vault
good first issue
help wanted
low priority
notes
pull-request
question
troubleshooting
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/vaultwarden#1067
No description provided.