starred/vaultwarden
1
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-02-05 00:29:40 +03:00
Code Issues 32 Packages Projects Releases 10 Wiki Activity

Update to 1.25.0 database update fails #1290

New Issue
Closed
opened 2026-02-05 00:32:32 +03:00 by OVERLORD · 14 comments
OVERLORD commented 2026-02-05 00:32:32 +03:00
Owner
Copy Link

Originally created by @ToeiRei on GitHub (May 31, 2022).

Subject of the issue

Vaultwarden constantly tries to update MySQL(mariadb) using 20220302210038/up.sql

Deployment environment

  • vaultwarden version: 1.24.0

  • Install method: docker on Fedora CoreOS

  • Clients used: n/a

  • Reverse proxy and version: nginx

  • MySQL/MariaDB or PostgreSQL version: 10.7.4-MariaDB-1:10.7.4+maria~bullseye - mariadb.org binary distribution

  • Other relevant details:

services:
  bitwarden:
    image: vaultwarden/server:1.24.0
    restart: unless-stopped
    ports:
      - "816:80/tcp"
      - "3012:3012/tcp"
    environment:
      - DOMAIN=https://vault.domain.here
      - WEBSOCKET_ENABLED=true
      - LOG_FILE="/data/bitwarden.log"
      - INVITATIONS_ALLOWED=true
      - ADMIN_TOKEN=${BITWARDEN_ADMIN_TOKEN}
      - SMTP_HOST=${BITWARDEN_SMTP_HOST}
      - SMTP_FROM=${BITWARDEN_SMTP_FROM}
      - SMTP_PORT=${BITWARDEN_SMTP_PORT}
      - DATABASE_URL=${BITWARDEN_DATABASE_URI}
      - ENABLE_DB_WAL=false
      - SIGNUPS_ALLOWED=false
      - SMTP_SECURITY=off
    volumes:
      - type: volume
        source: bitwarden-data
        target: /data

Steps to reproduce

  1. have 1.24.0 running
  2. pull 1.25.0
  3. try to update
  4. wonder why vaultwarden is still down
  5. examine logs

Expected behaviour

I would expect the diesel_schema_migration to just do its job and call it a day

Actual behaviour

Migration is run over and over and over ... again.

Troubleshooting data

docker logs:

/--------------------------------------------------------------------\
 |                        Starting Vaultwarden                        |
 |                           Version 1.25.0                           |
 |--------------------------------------------------------------------|
 | This is an *unofficial* Bitwarden implementation, DO NOT use the   |
 | official channels to report bugs/features, regardless of client.   |
 | Send usage/configuration questions or feature requests to:         |
 |   https://vaultwarden.discourse.group/                             |
 | Report suspected bugs/issues in the software itself at:            |
 |   https://github.com/dani-garcia/vaultwarden/issues/new            |
 \--------------------------------------------------------------------/

 [INFO] No .env file found.
 [WARNING] The following environment variables are being overriden by the config file,
 [WARNING] please use the admin panel to make changes to them:
 [WARNING] DOMAIN, SIGNUPS_ALLOWED, INVITATIONS_ALLOWED, ADMIN_TOKEN, SMTP_HOST, SMTP_PORT, SMTP_FROM
 Running migration 20220302210038
 Executing migration script 20220302210038/up.sql
 Running migration 20220302210038
 Executing migration script 20220302210038/up.sql
 Running migration 20220302210038
 Executing migration script 20220302210038/up.sql
 Running migration 20220302210038
 Executing migration script 20220302210038/up.sql
 Running migration 20220302210038
 Executing migration script 20220302210038/up.sql
 Running migration 20220302210038
 Executing migration script 20220302210038/up.sql
Originally created by @ToeiRei on GitHub (May 31, 2022). ### Subject of the issue Vaultwarden constantly tries to update MySQL(mariadb) using 20220302210038/up.sql ### Deployment environment * vaultwarden version: 1.24.0 * Install method: docker on Fedora CoreOS * Clients used: n/a * Reverse proxy and version: nginx * MySQL/MariaDB or PostgreSQL version: 10.7.4-MariaDB-1:10.7.4+maria~bullseye - mariadb.org binary distribution * Other relevant details: ``` services: bitwarden: image: vaultwarden/server:1.24.0 restart: unless-stopped ports: - "816:80/tcp" - "3012:3012/tcp" environment: - DOMAIN=https://vault.domain.here - WEBSOCKET_ENABLED=true - LOG_FILE="/data/bitwarden.log" - INVITATIONS_ALLOWED=true - ADMIN_TOKEN=${BITWARDEN_ADMIN_TOKEN} - SMTP_HOST=${BITWARDEN_SMTP_HOST} - SMTP_FROM=${BITWARDEN_SMTP_FROM} - SMTP_PORT=${BITWARDEN_SMTP_PORT} - DATABASE_URL=${BITWARDEN_DATABASE_URI} - ENABLE_DB_WAL=false - SIGNUPS_ALLOWED=false - SMTP_SECURITY=off volumes: - type: volume source: bitwarden-data target: /data ``` ### Steps to reproduce 1. have 1.24.0 running 2. pull 1.25.0 3. try to update 4. wonder why vaultwarden is still down 5. examine logs ### Expected behaviour I would expect the diesel_schema_migration to just do its job and call it a day ### Actual behaviour Migration is run over and over and over ... again. ### Troubleshooting data docker logs: ``` /--------------------------------------------------------------------\ | Starting Vaultwarden | | Version 1.25.0 | |--------------------------------------------------------------------| | This is an *unofficial* Bitwarden implementation, DO NOT use the | | official channels to report bugs/features, regardless of client. | | Send usage/configuration questions or feature requests to: | | https://vaultwarden.discourse.group/ | | Report suspected bugs/issues in the software itself at: | | https://github.com/dani-garcia/vaultwarden/issues/new | \--------------------------------------------------------------------/ [INFO] No .env file found. [WARNING] The following environment variables are being overriden by the config file, [WARNING] please use the admin panel to make changes to them: [WARNING] DOMAIN, SIGNUPS_ALLOWED, INVITATIONS_ALLOWED, ADMIN_TOKEN, SMTP_HOST, SMTP_PORT, SMTP_FROM Running migration 20220302210038 Executing migration script 20220302210038/up.sql Running migration 20220302210038 Executing migration script 20220302210038/up.sql Running migration 20220302210038 Executing migration script 20220302210038/up.sql Running migration 20220302210038 Executing migration script 20220302210038/up.sql Running migration 20220302210038 Executing migration script 20220302210038/up.sql Running migration 20220302210038 Executing migration script 20220302210038/up.sql ```
OVERLORD commented 2026-02-05 00:32:38 +03:00
Author
Owner
Copy Link

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

Please checkout: https://github.com/dani-garcia/vaultwarden/wiki/Using-the-MariaDB-(MySQL)-Backend/#foreign-key-errors-collation-and-charset follow those steps and see if that fixes your issue.

@BlackDex commented on GitHub (May 31, 2022): Please checkout: https://github.com/dani-garcia/vaultwarden/wiki/Using-the-MariaDB-(MySQL)-Backend/#foreign-key-errors-collation-and-charset follow those steps and see if that fixes your issue.
OVERLORD commented 2026-02-05 00:32:40 +03:00
Author
Owner
Copy Link

@ToeiRei commented on GitHub (May 31, 2022):

My database is already utf8mb4_unicode_ci

@ToeiRei commented on GitHub (May 31, 2022): My database is already utf8mb4_unicode_ci
OVERLORD commented 2026-02-05 00:32:44 +03:00
Author
Owner
Copy Link

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

Is that the same for all the tables? Those could be different sometimes.
Also, try to set LOG_LEVEL=debug to see if that gives a bit more info.

Also, double check the integrity of the __diesel_schema_migrations table and maybe execute an optimize on it so that it gets re-created.

@BlackDex commented on GitHub (May 31, 2022): Is that the same for all the tables? Those could be different sometimes. Also, try to set `LOG_LEVEL=debug` to see if that gives a bit more info. Also, double check the integrity of the `__diesel_schema_migrations` table and maybe execute an optimize on it so that it gets re-created.
OVERLORD commented 2026-02-05 00:32:49 +03:00
Author
Owner
Copy Link

@ToeiRei commented on GitHub (May 31, 2022):

image

As you do not seem to live the "screenshot or it didn't happen" philosophy, here is one. My database gets optimized every night right after the backup cycle to make sure it's good for the next day.

@ToeiRei commented on GitHub (May 31, 2022): ![image](https://user-images.githubusercontent.com/5990591/171139524-49d091f2-2331-4158-b1db-f27be7074e58.png) As you do not seem to live the "screenshot or it didn't happen" philosophy, here is one. My database gets optimized every night right after the backup cycle to make sure it's good for the next day.
OVERLORD commented 2026-02-05 00:32:55 +03:00
Author
Owner
Copy Link

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

Can you show the contents of the __diesel_schema_migrations, since it looks like that isn't updated and that causes the the migration to repeat.

@BlackDex commented on GitHub (May 31, 2022): Can you show the contents of the `__diesel_schema_migrations`, since it looks like that isn't updated and that causes the the migration to repeat.
OVERLORD commented 2026-02-05 00:32:58 +03:00
Author
Owner
Copy Link

@ToeiRei commented on GitHub (May 31, 2022):

There is no entry in this table reflecting 20220302210038. I was trying to add one manually, no joy - as this was one of my first ideas (doing the update manually)
Debug sadly doesn't give more info.

@ToeiRei commented on GitHub (May 31, 2022): There is no entry in this table reflecting 20220302210038. I was trying to add one manually, no joy - as this was one of my first ideas (doing the update manually) Debug sadly doesn't give more info.
OVERLORD commented 2026-02-05 00:33:01 +03:00
Author
Owner
Copy Link

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

Are there any errors or other logs for the database maybe?

@BlackDex commented on GitHub (May 31, 2022): Are there any errors or other logs for the database maybe?
OVERLORD commented 2026-02-05 00:33:05 +03:00
Author
Owner
Copy Link

@ToeiRei commented on GitHub (May 31, 2022):

MariaDB doesn't complain.

@ToeiRei commented on GitHub (May 31, 2022): MariaDB doesn't complain.
OVERLORD commented 2026-02-05 00:33:08 +03:00
Author
Owner
Copy Link

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

I'm not sure why this is not working then.
It looks like Vaultwarden can't execute something for some reason, or isn't able to execute the migration, maybe it doesn't have to correct rights, i have no clue without any more information then this.

What happens if you create a new database and run the latest Vaultwarden on that database?
Is that able to run all the other migrations, and then still gets stuck there?

@BlackDex commented on GitHub (May 31, 2022): I'm not sure why this is not working then. It looks like Vaultwarden can't execute something for some reason, or isn't able to execute the migration, maybe it doesn't have to correct rights, i have no clue without any more information then this. What happens if you create a new database and run the latest Vaultwarden on that database? Is that able to run all the other migrations, and then still gets stuck there?
OVERLORD commented 2026-02-05 00:33:11 +03:00
Author
Owner
Copy Link

@ToeiRei commented on GitHub (May 31, 2022):

The vaultwarden sql user got full permissions on the database - so I can rule out the permission thing. Migration commands itself check out without issues.
I can't just run it on a fresh database right now as I've got users using it.

@ToeiRei commented on GitHub (May 31, 2022): The vaultwarden sql user got full permissions on the database - so I can rule out the permission thing. Migration commands itself check out without issues. I can't just run it on a fresh database right now as I've got users using it.
OVERLORD commented 2026-02-05 00:33:14 +03:00
Author
Owner
Copy Link

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

Well, you could always run a second instance on a different database, but anyways.

Try to do the following.

  1. Remove the manually added record from the __diesel_schema_migrations
  2. Run the following queries one after each other:
-- First remove the previous primary key
ALTER TABLE devices DROP PRIMARY KEY;
-- Add a new combined one
ALTER TABLE devices ADD PRIMARY KEY (uuid, user_uuid);
  1. If that works run the following query:
-- Update the migrations table
INSERT INTO `__diesel_schema_migrations` VALUES ("20220302210038", NOW());

Now change to the latest version of Vaultwarden again, and that should fix the issue.
This is what the migration script should be doing, but for some reason that seems to have issues on your setup.

@BlackDex commented on GitHub (May 31, 2022): Well, you could always run a second instance on a different database, but anyways. Try to do the following. 1. Remove the manually added record from the `__diesel_schema_migrations` 2. Run the following queries one after each other: ```sql -- First remove the previous primary key ALTER TABLE devices DROP PRIMARY KEY; -- Add a new combined one ALTER TABLE devices ADD PRIMARY KEY (uuid, user_uuid); ``` 3. If that works run the following query: ```sql -- Update the migrations table INSERT INTO `__diesel_schema_migrations` VALUES ("20220302210038", NOW()); ``` Now change to the latest version of Vaultwarden again, and that should fix the issue. This is what the migration script should be doing, but for some reason that seems to have issues on your setup.
OVERLORD commented 2026-02-05 00:33:16 +03:00
Author
Owner
Copy Link

@ToeiRei commented on GitHub (May 31, 2022):

That's exactly what I said in the previous comment.

@ToeiRei commented on GitHub (May 31, 2022): That's exactly what I said in the previous comment.
OVERLORD commented 2026-02-05 00:33:18 +03:00
Author
Owner
Copy Link

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

Well, you said that you added the record to the migrations table, not that you executed those other queries.
If you are 100% sure that that exact string of numbers is in there, no spaces or other characters which are prepending or appending it like spaces or whatever, then the migration should not happen at all.

The migration tooling check that table for that exact same string and if that is there it will not run the migration.
So if you are 100% sure it is there, I'm actually not sure what to do.

I can't reproduce it my self no matter what i try to do.
If you do not get any errors from changing the the PRIMARY KEY query, and the table DDL is looking exactly the same as this:

-- vaultwarden.devices definition

CREATE TABLE `devices` (
  `uuid` char(36) COLLATE utf8mb4_unicode_ci NOT NULL,
  `created_at` datetime NOT NULL,
  `updated_at` datetime NOT NULL,
  `user_uuid` char(36) COLLATE utf8mb4_unicode_ci NOT NULL,
  `name` text COLLATE utf8mb4_unicode_ci NOT NULL,
  `atype` int(11) NOT NULL,
  `push_token` text COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `refresh_token` text COLLATE utf8mb4_unicode_ci NOT NULL,
  `twofactor_remember` text COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  PRIMARY KEY (`uuid`,`user_uuid`),
  KEY `user_uuid` (`user_uuid`),
  CONSTRAINT `devices_ibfk_1` FOREIGN KEY (`user_uuid`) REFERENCES `users` (`uuid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

Then it should just be working. If not, then I'm out of options to check right now, except for running a separate Vaultwarden container using the exact same configuration as you are having right now on a new empty database and see if that wants to run or not. Or maybe even try to copy/clone the current database to vaultwarden_new and use that and see what happens.

There isn't anything we can do on the server side I'm afraid.

@BlackDex commented on GitHub (May 31, 2022): Well, you said that you added the record to the migrations table, not that you executed those other queries. If you are 100% sure that that exact string of numbers is in there, no spaces or other characters which are prepending or appending it like spaces or whatever, then the migration should not happen at all. The migration tooling check that table for that exact same string and if that is there it will not run the migration. So if you are 100% sure it is there, I'm actually not sure what to do. I can't reproduce it my self no matter what i try to do. If you do not get any errors from changing the the `PRIMARY KEY` query, and the table DDL is looking exactly the same as this: ```sql -- vaultwarden.devices definition CREATE TABLE `devices` ( `uuid` char(36) COLLATE utf8mb4_unicode_ci NOT NULL, `created_at` datetime NOT NULL, `updated_at` datetime NOT NULL, `user_uuid` char(36) COLLATE utf8mb4_unicode_ci NOT NULL, `name` text COLLATE utf8mb4_unicode_ci NOT NULL, `atype` int(11) NOT NULL, `push_token` text COLLATE utf8mb4_unicode_ci DEFAULT NULL, `refresh_token` text COLLATE utf8mb4_unicode_ci NOT NULL, `twofactor_remember` text COLLATE utf8mb4_unicode_ci DEFAULT NULL, PRIMARY KEY (`uuid`,`user_uuid`), KEY `user_uuid` (`user_uuid`), CONSTRAINT `devices_ibfk_1` FOREIGN KEY (`user_uuid`) REFERENCES `users` (`uuid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; ``` Then it should just be working. If not, then I'm out of options to check right now, except for running a separate Vaultwarden container using the exact same configuration as you are having right now on a new empty database and see if that wants to run or not. Or maybe even try to copy/clone the current database to `vaultwarden_new` and use that and see what happens. There isn't anything we can do on the server side I'm afraid.
OVERLORD commented 2026-02-05 00:33:20 +03:00
Author
Owner
Copy Link

@ToeiRei commented on GitHub (May 31, 2022):

I'll just stay on it and see if I can reproduce it; If not, I'll just call it a fluke, reboot and carry on.

@ToeiRei commented on GitHub (May 31, 2022): I'll just stay on it and see if I can reproduce it; If not, I'll just call it a fluke, reboot and carry on.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
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 Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/vaultwarden#1290
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?