Can't connect to database after update docker image to 1.25.0 #1282

Closed
opened 2025-11-07 07:02:36 -06:00 by GiteaMirror · 14 comments
Owner

Originally created by @Hobbabobba on GitHub (May 26, 2022).

Subject of the issue

Updated docker image to vaultwarden/server:1.25.0

After that container can´t start

Deployment environment

  • vaultwarden version: 1.25.0
  • Install method: Docker-Compose
version: "2"
services:
  bitwarden:
    image: vaultwarden/server
    container_name: vaultwarden
    environment:
      - WEBSOCKET_ENABLED=true
      - SIGNUPS_ALLOWED=false
      - ADMIN_TOKEN=xxx
      - SMTP_PASSWORD=xxxx
      - SMTP_USERNAME=mail@domain.com
      - SMTP_SSL=true
      - SMTP_PORT=587
      - SMTP_FROM=yyyy
      - SMTP_HOST=yyy
    volumes:
      - /volume1/docker/bitwarden_rs:/data
    ports:
      - 3012:3012
      - 6680:80
    restart: always
  • Clients used:

web vault
Desktop
Android
iOS

  • Other relevant details:

Steps to reproduce

Expected behaviour

Actual behaviour

Troubleshooting data

)
Running migration 20220302210038
Executing migration script 20220302210038/up.sql
[2022-05-26 21:23:36.150][vaultwarden::util][WARN] Can't connect to database, retrying: DieselMig.
[CAUSE] QueryError(
    DatabaseError(
        __Unknown,
        "UNIQUE constraint failed: devices_new.uuid, devices_new.user_uuid",
    ),
)
Originally created by @Hobbabobba on GitHub (May 26, 2022). ### Subject of the issue Updated docker image to vaultwarden/server:1.25.0 After that container can´t start ### Deployment environment <!-- ========================================================================================= Preferably, use the `Generate Support String` button on the admin page's Diagnostics tab. That will auto-generate most of the info requested in this section. ========================================================================================= --> <!-- The version number, obtained from the logs (at startup) or the admin diagnostics page --> <!-- This is NOT the version number shown on the web vault, which is versioned separately from vaultwarden --> <!-- Remember to check if your issue exists on the latest version first! --> * vaultwarden version: 1.25.0 <!-- How the server was installed: Docker image, OS package, built from source, etc. --> * Install method: Docker-Compose ``` version: "2" services: bitwarden: image: vaultwarden/server container_name: vaultwarden environment: - WEBSOCKET_ENABLED=true - SIGNUPS_ALLOWED=false - ADMIN_TOKEN=xxx - SMTP_PASSWORD=xxxx - SMTP_USERNAME=mail@domain.com - SMTP_SSL=true - SMTP_PORT=587 - SMTP_FROM=yyyy - SMTP_HOST=yyy volumes: - /volume1/docker/bitwarden_rs:/data ports: - 3012:3012 - 6680:80 restart: always ``` * Clients used: <!-- web vault, desktop, Android, iOS, etc. (if applicable) --> web vault Desktop Android iOS * Other relevant details: ### Steps to reproduce <!-- Tell us how to reproduce this issue. What parameters did you set (differently from the defaults) and how did you start vaultwarden? --> ### Expected behaviour <!-- Tell us what you expected to happen --> ### Actual behaviour <!-- Tell us what actually happened --> ### Troubleshooting data <!-- Share any log files, screenshots, or other relevant troubleshooting data --> ``` ) Running migration 20220302210038 Executing migration script 20220302210038/up.sql [2022-05-26 21:23:36.150][vaultwarden::util][WARN] Can't connect to database, retrying: DieselMig. [CAUSE] QueryError( DatabaseError( __Unknown, "UNIQUE constraint failed: devices_new.uuid, devices_new.user_uuid", ), ) ```
Author
Owner

@BlackDex commented on GitHub (May 26, 2022):

Please check https://github.com/dani-garcia/vaultwarden/wiki/Using-the-MariaDB-%28MySQL%29-Backend#foreign-key-errors-collation-and-charset and follow the steps there. It probably has some wrong configuration on the database or tables.

@BlackDex commented on GitHub (May 26, 2022): Please check https://github.com/dani-garcia/vaultwarden/wiki/Using-the-MariaDB-%28MySQL%29-Backend#foreign-key-errors-collation-and-charset and follow the steps there. It probably has some wrong configuration on the database or tables.
Author
Owner

@Hobbabobba commented on GitHub (May 26, 2022):

how can I do any of the steps in https://github.com/dani-garcia/vaultwarden/wiki/Using-the-MariaDB-%28MySQL%29-Backend#foreign-key-errors-collation-and-charset ? Using the commands inside the docker cli does not work.

@Hobbabobba commented on GitHub (May 26, 2022): how can I do any of the steps in https://github.com/dani-garcia/vaultwarden/wiki/Using-the-MariaDB-%28MySQL%29-Backend#foreign-key-errors-collation-and-charset ? Using the commands inside the docker cli does not work.
Author
Owner

@BlackDex commented on GitHub (May 26, 2022):

Hmm, it's a sqlite db it looks like.
Strange, the migration should just run.

@BlackDex commented on GitHub (May 26, 2022): Hmm, it's a sqlite db it looks like. Strange, the migration should just run.
Author
Owner

@Hobbabobba commented on GitHub (May 26, 2022):

if i don´t mount the data-volume the migration works and the container is running fine. After mount the volume again, the problem still occurs. Image 1.24.0 works without any problem.

@Hobbabobba commented on GitHub (May 26, 2022): if i don´t mount the data-volume the migration works and the container is running fine. After mount the volume again, the problem still occurs. Image 1.24.0 works without any problem.
Author
Owner

@berotrip commented on GitHub (May 27, 2022):

Can't contribute anything but say that I am having the exact same problem since 1.25.0 and had to revert back to version 1.24.0 where it still works.

No external DB configured, just the integrated sqlite inside the container.
I wonder what is the reason a migration script starts up?

@berotrip commented on GitHub (May 27, 2022): Can't contribute anything but say that I am having the exact same problem since 1.25.0 and had to revert back to version 1.24.0 where it still works. No external DB configured, just the integrated sqlite inside the container. I wonder what is the reason a migration script starts up?
Author
Owner

@BlackDex commented on GitHub (May 27, 2022):

The reason is because there are some changes to the database.
I didn't had time yet to do some testing regarding this issue.

@BlackDex commented on GitHub (May 27, 2022): The reason is because there are some changes to the database. I didn't had time yet to do some testing regarding this issue.
Author
Owner

@walmer26 commented on GitHub (May 28, 2022):

Same issue here.

@walmer26 commented on GitHub (May 28, 2022): Same issue here.
Author
Owner

@BlackDex commented on GitHub (May 28, 2022):

Ok, i have tried several stuff to try and reproduce this but were not able to.
What could be the case here is that there is something wrong with the database it self. It might not be a big issue, but still.

Could someone try to do the following:

  1. Create a backup of the database before you continue.
    So, just copy over the db.sqlite3 file and rename it to something like backup_db.sqlite3 or what ever.
  2. Now we need a second kinda of backup which is a bit different then just coping the file.
    a. Either login into the admin interface, scroll all the way down there is a backup option there, run that, and there should be a new backup file generated next to the default database file.
    b. Run sqlite command your self. I suggest to shutdown Vaultwarden first when you do this your self.
    Go to the data folder where the db.sqlite3 file is located and run
    sqlite3 db.sqlite3 "VACUUM INTO './db-vacumed.sqlite3'"
    
  3. I any case, make sure to stop Vaultwarden.
  4. Move/Rename the original db.sqlite3 file
  5. Now Move/Rename the newly generated backuped/vacumed file to be db.sqlite3
  6. Start Vaultwarden again, and see if this solves the issue.
@BlackDex commented on GitHub (May 28, 2022): Ok, i have tried several stuff to try and reproduce this but were not able to. What could be the case here is that there is something wrong with the database it self. It might not be a big issue, but still. Could someone try to do the following: 1. Create a backup of the database before you continue. So, just copy over the `db.sqlite3` file and rename it to something like `backup_db.sqlite3` or what ever. 2. Now we need a second kinda of backup which is a bit different then just coping the file. a. Either login into the admin interface, scroll all the way down there is a backup option there, run that, and there should be a new backup file generated next to the default database file. b. Run sqlite command your self. I suggest to shutdown Vaultwarden first when you do this your self. Go to the data folder where the `db.sqlite3` file is located and run ```bash sqlite3 db.sqlite3 "VACUUM INTO './db-vacumed.sqlite3'" ``` 3. I any case, make sure to stop Vaultwarden. 4. Move/Rename the original `db.sqlite3` file 5. Now Move/Rename the newly generated backuped/vacumed file to be `db.sqlite3` 6. Start Vaultwarden again, and see if this solves the issue.
Author
Owner

@Hobbabobba commented on GitHub (May 28, 2022):

I tried the fix with a vacumed db, still the same problem after an update to 1.25.0

@Hobbabobba commented on GitHub (May 28, 2022): I tried the fix with a vacumed db, still the same problem after an update to 1.25.0
Author
Owner

@BlackDex commented on GitHub (May 28, 2022):

Could you post a sqlite3 db.sqlite3 '.schema;' here?
Need to see what is wrong here.

@BlackDex commented on GitHub (May 28, 2022): Could you post a `sqlite3 db.sqlite3 '.schema;'` here? Need to see what is wrong here.
Author
Owner

@berotrip commented on GitHub (May 28, 2022):

Here's the schema (no success with VACUUM):

SQLite version 3.31.1 2020-01-27 19:55:54
Enter ".help" for usage hints.
sqlite> .schema
CREATE TABLE __diesel_schema_migrations (version VARCHAR(50) PRIMARY KEY NOT NULL,run_on TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP);
CREATE TABLE users (
  uuid                TEXT     NOT NULL PRIMARY KEY,
  created_at          DATETIME NOT NULL,
  updated_at          DATETIME NOT NULL,
  email               TEXT     NOT NULL UNIQUE,
  name                TEXT     NOT NULL,
  password_hash       BLOB     NOT NULL,
  salt                BLOB     NOT NULL,
  password_iterations INTEGER  NOT NULL,
  password_hint       TEXT,
  akey                 TEXT     NOT NULL,
  private_key         TEXT,
  public_key          TEXT,
  totp_secret         TEXT,
  totp_recover        TEXT,
  security_stamp      TEXT     NOT NULL,
  equivalent_domains  TEXT     NOT NULL,
  excluded_globals    TEXT     NOT NULL
, client_kdf_type INTEGER NOT NULL DEFAULT 0, client_kdf_iter INTEGER NOT NULL DEFAULT 100000, verified_at DATETIME DEFAULT NULL, last_verifying_at DATETIME DEFAULT NULL, login_verify_count INTEGER NOT NULL DEFAULT 0, email_new TEXT DEFAULT NULL, email_new_token TEXT DEFAULT NULL, enabled BOOLEAN NOT NULL DEFAULT 1, stamp_exception TEXT DEFAULT NULL, api_key TEXT);
CREATE TABLE devices (
  uuid          TEXT     NOT NULL PRIMARY KEY,
  created_at    DATETIME NOT NULL,
  updated_at    DATETIME NOT NULL,
  user_uuid     TEXT     NOT NULL REFERENCES users (uuid),
  name          TEXT     NOT NULL,
  atype          INTEGER  NOT NULL,
  push_token    TEXT,
  refresh_token TEXT     NOT NULL
, twofactor_remember TEXT);
CREATE TABLE folders (
  uuid       TEXT     NOT NULL PRIMARY KEY,
  created_at DATETIME NOT NULL,
  updated_at DATETIME NOT NULL,
  user_uuid  TEXT     NOT NULL REFERENCES users (uuid),
  name       TEXT     NOT NULL
);
CREATE TABLE collections (
  uuid     TEXT NOT NULL PRIMARY KEY,
  org_uuid TEXT NOT NULL REFERENCES organizations (uuid),
  name     TEXT NOT NULL
);
CREATE TABLE organizations (
  uuid          TEXT NOT NULL PRIMARY KEY,
  name          TEXT NOT NULL,
  billing_email TEXT NOT NULL
, private_key TEXT, public_key TEXT);
CREATE TABLE users_collections (
  user_uuid       TEXT NOT NULL REFERENCES users (uuid),
  collection_uuid TEXT NOT NULL REFERENCES collections (uuid), read_only BOOLEAN NOT NULL DEFAULT 0, hide_passwords BOOLEAN NOT NULL DEFAULT 0,
  PRIMARY KEY (user_uuid, collection_uuid)
);
CREATE TABLE users_organizations (
  uuid       TEXT    NOT NULL PRIMARY KEY,
  user_uuid  TEXT    NOT NULL REFERENCES users (uuid),
  org_uuid   TEXT    NOT NULL REFERENCES organizations (uuid),

  access_all BOOLEAN NOT NULL,

, reprompt INTEGER);
CREATE TABLE sends (
  uuid              TEXT NOT NULL   PRIMARY KEY,
  user_uuid         TEXT            REFERENCES users (uuid),
  organization_uuid TEXT            REFERENCES organizations (uuid),

  name              TEXT    NOT NULL,
  notes             TEXT,

  atype             INTEGER NOT NULL,
  data              TEXT    NOT NULL,
  akey               TEXT    NOT NULL,
  password_hash     BLOB,
  password_salt     BLOB,
  password_iter     INTEGER,

  max_access_count  INTEGER,
  access_count      INTEGER NOT NULL,

  creation_date     DATETIME NOT NULL,
  revision_date     DATETIME NOT NULL,
  expiration_date   DATETIME,
  deletion_date     DATETIME NOT NULL,

  disabled          BOOLEAN NOT NULL
, hide_email BOOLEAN);
CREATE TABLE emergency_access (
  uuid                      TEXT     NOT NULL PRIMARY KEY,
  grantor_uuid              TEXT     REFERENCES users (uuid),
  grantee_uuid              TEXT     REFERENCES users (uuid),
  email                     TEXT,
  key_encrypted             TEXT,
  atype                     INTEGER  NOT NULL,
  status                    INTEGER  NOT NULL,
  wait_time_days            INTEGER  NOT NULL,
  recovery_initiated_at     DATETIME,
  last_notification_at      DATETIME,
  updated_at                DATETIME NOT NULL,
  created_at                DATETIME NOT NULL
);
CREATE TABLE twofactor_incomplete (
  user_uuid   TEXT     NOT NULL REFERENCES users(uuid),
  device_uuid TEXT     NOT NULL,
  device_name TEXT     NOT NULL,
  login_time  DATETIME NOT NULL,
  ip_address  TEXT     NOT NULL,

  PRIMARY KEY (user_uuid, device_uuid)
);
sqlite>

Could the last line be relevant: device_uuid instead of the quoted devices_uuid from the error messages?

@berotrip commented on GitHub (May 28, 2022): Here's the schema (no success with VACUUM): ``` SQLite version 3.31.1 2020-01-27 19:55:54 Enter ".help" for usage hints. sqlite> .schema CREATE TABLE __diesel_schema_migrations (version VARCHAR(50) PRIMARY KEY NOT NULL,run_on TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP); CREATE TABLE users ( uuid TEXT NOT NULL PRIMARY KEY, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL, email TEXT NOT NULL UNIQUE, name TEXT NOT NULL, password_hash BLOB NOT NULL, salt BLOB NOT NULL, password_iterations INTEGER NOT NULL, password_hint TEXT, akey TEXT NOT NULL, private_key TEXT, public_key TEXT, totp_secret TEXT, totp_recover TEXT, security_stamp TEXT NOT NULL, equivalent_domains TEXT NOT NULL, excluded_globals TEXT NOT NULL , client_kdf_type INTEGER NOT NULL DEFAULT 0, client_kdf_iter INTEGER NOT NULL DEFAULT 100000, verified_at DATETIME DEFAULT NULL, last_verifying_at DATETIME DEFAULT NULL, login_verify_count INTEGER NOT NULL DEFAULT 0, email_new TEXT DEFAULT NULL, email_new_token TEXT DEFAULT NULL, enabled BOOLEAN NOT NULL DEFAULT 1, stamp_exception TEXT DEFAULT NULL, api_key TEXT); CREATE TABLE devices ( uuid TEXT NOT NULL PRIMARY KEY, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL, user_uuid TEXT NOT NULL REFERENCES users (uuid), name TEXT NOT NULL, atype INTEGER NOT NULL, push_token TEXT, refresh_token TEXT NOT NULL , twofactor_remember TEXT); CREATE TABLE folders ( uuid TEXT NOT NULL PRIMARY KEY, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL, user_uuid TEXT NOT NULL REFERENCES users (uuid), name TEXT NOT NULL ); CREATE TABLE collections ( uuid TEXT NOT NULL PRIMARY KEY, org_uuid TEXT NOT NULL REFERENCES organizations (uuid), name TEXT NOT NULL ); CREATE TABLE organizations ( uuid TEXT NOT NULL PRIMARY KEY, name TEXT NOT NULL, billing_email TEXT NOT NULL , private_key TEXT, public_key TEXT); CREATE TABLE users_collections ( user_uuid TEXT NOT NULL REFERENCES users (uuid), collection_uuid TEXT NOT NULL REFERENCES collections (uuid), read_only BOOLEAN NOT NULL DEFAULT 0, hide_passwords BOOLEAN NOT NULL DEFAULT 0, PRIMARY KEY (user_uuid, collection_uuid) ); CREATE TABLE users_organizations ( uuid TEXT NOT NULL PRIMARY KEY, user_uuid TEXT NOT NULL REFERENCES users (uuid), org_uuid TEXT NOT NULL REFERENCES organizations (uuid), access_all BOOLEAN NOT NULL, , reprompt INTEGER); CREATE TABLE sends ( uuid TEXT NOT NULL PRIMARY KEY, user_uuid TEXT REFERENCES users (uuid), organization_uuid TEXT REFERENCES organizations (uuid), name TEXT NOT NULL, notes TEXT, atype INTEGER NOT NULL, data TEXT NOT NULL, akey TEXT NOT NULL, password_hash BLOB, password_salt BLOB, password_iter INTEGER, max_access_count INTEGER, access_count INTEGER NOT NULL, creation_date DATETIME NOT NULL, revision_date DATETIME NOT NULL, expiration_date DATETIME, deletion_date DATETIME NOT NULL, disabled BOOLEAN NOT NULL , hide_email BOOLEAN); CREATE TABLE emergency_access ( uuid TEXT NOT NULL PRIMARY KEY, grantor_uuid TEXT REFERENCES users (uuid), grantee_uuid TEXT REFERENCES users (uuid), email TEXT, key_encrypted TEXT, atype INTEGER NOT NULL, status INTEGER NOT NULL, wait_time_days INTEGER NOT NULL, recovery_initiated_at DATETIME, last_notification_at DATETIME, updated_at DATETIME NOT NULL, created_at DATETIME NOT NULL ); CREATE TABLE twofactor_incomplete ( user_uuid TEXT NOT NULL REFERENCES users(uuid), device_uuid TEXT NOT NULL, device_name TEXT NOT NULL, login_time DATETIME NOT NULL, ip_address TEXT NOT NULL, PRIMARY KEY (user_uuid, device_uuid) ); sqlite> ``` Could the last line be relevant: device_uuid instead of the quoted device**s**_uuid from the error messages?
Author
Owner

@BlackDex commented on GitHub (May 28, 2022):

Seems to look fine. And those two items are totally different.

The only step left i can think of is that you need to clear the devices table.
You can do that by going to the admin interface /admin/users/overview and click on Deauthorize sessions for every user you have. That will force all clients to logout and they need to login again though.

But after you clicked on Deauthorize sessions for every user, try to upgrade again, and see if that helps?

@BlackDex commented on GitHub (May 28, 2022): Seems to look fine. And those two items are totally different. The only step left i can think of is that you need to clear the `devices` table. You can do that by going to the admin interface `/admin/users/overview` and click on `Deauthorize sessions` for every user you have. That will force all clients to logout and they need to login again though. But after you clicked on `Deauthorize sessions` for every user, try to upgrade again, and see if that helps?
Author
Owner

@berotrip commented on GitHub (May 28, 2022):

But after you clicked on Deauthorize sessions for every user, try to upgrade again, and see if that helps?

That worked, thanks!

Running migration 20220302210038
[2022-05-28 16:00:00.409][parity_ws][INFO] Listening for new connections on 0.0.0.0:3012.
@berotrip commented on GitHub (May 28, 2022): > But after you clicked on Deauthorize sessions for every user, try to upgrade again, and see if that helps? That worked, thanks! ``` Running migration 20220302210038 [2022-05-28 16:00:00.409][parity_ws][INFO] Listening for new connections on 0.0.0.0:3012. ```
Author
Owner

@Hobbabobba commented on GitHub (May 28, 2022):

But after you clicked on Deauthorize sessions for every user, try to upgrade again, and see if that helps?

Fixed it!

@Hobbabobba commented on GitHub (May 28, 2022): > But after you clicked on Deauthorize sessions for every user, try to upgrade again, and see if that helps? Fixed it!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#1282