Vaultwarden fails to start after update – DB migration error (SSO)
-
Hello @factord
This is due to your forum profile settings.
If you visit https://forum.cloudron.io/user/factord/settings you can see underNotificationsthe optionWhen someone mentions youis set toNone.
If you wish to get notifications on mention, you will have to enable this.
Although, you should have got a notification that there were new posts in this topic unless you have changed the topic notification status toNot WatchingorIgnoringsince in your forum profile settings the following is set:
Did you change the notification setting in this topic (top right bell icon)?
-
I've got an error during upgrade of Vaultwarden from
1.22.2to1.23.0or more1.24.0etc... :Please generate a secure Argon2 PHC string by using `vaultwarden hash` or `argon2`. Jan 17 19:10:33 See: https://github.com/dani-garcia/vaultwarden/wiki/Enabling-admin-page#secure-the-admin_token Jan 17 19:10:33 2026-01-17T19:10:33+01:00 Jan 17 19:10:34 [2026-01-17 18:10:34.083][panic][ERROR] thread 'main' panicked at 'Error running migrations: QueryError(DieselMigrationName { name: "2024-03-06-170000_add_sso_users", version: MigrationVersion("20240306170000") }, DatabaseError(Unknown, "Referencing column 'user_uuid' and referenced column 'uuid' in foreign key constraint 'sso_users_ibfk_1' are incompatible."))': src/db/mod.rs:505 Jan 17 19:10:34 0: vaultwarden::init_logging::{{closure}} Jan 17 19:10:34 1: std::panicking::panic_with_hook Jan 17 19:10:34 2: std::panicking::panic_handler::{{closure}} Jan 17 19:10:34 3: std::sys::backtrace::__rust_end_short_backtrace Jan 17 19:10:34 4: __rustc::rust_begin_unwind Jan 17 19:10:34 5: core::panicking::panic_fmt Jan 17 19:10:34 6: core::result::unwrap_failed Jan 17 19:10:34 7: vaultwarden::db::DbPool::from_config Jan 17 19:10:34 8: vaultwarden::main::{{closure}} Jan 17 19:10:34 9: vaultwarden::main Jan 17 19:10:34 10: std::sys::backtrace::__rust_begin_short_backtrace Jan 17 19:10:34 11: main Jan 17 19:10:34 12: <unknown> Jan 17 19:10:34 13: __libc_start_main Jan 17 19:10:34 14: _start Jan 17 19:10:34 2026-01-17T19:10:34+01:00Can you help me ?
Regards
-
I assume this may be more of Vaultwarden issue than a Cloudron one but I wanted to say the recent image update (https://forum.cloudron.io/topic/2546/vaultwarden-package-updates/79?_=1778039394241) seems to have broken Vaultwarden, requiring me to restore from backup.
May 05 20:47:32 => Exporting env vars expected by Vaultwarden May 05 20:47:32 => Starting Bitwarden May 05 20:47:32 /--------------------------------------------------------------------\ May 05 20:47:32 | Starting Vaultwarden | May 05 20:47:32 |--------------------------------------------------------------------| May 05 20:47:32 | This is an *unofficial* Bitwarden implementation, DO NOT use the | May 05 20:47:32 | official channels to report bugs/features, regardless of client. | May 05 20:47:32 | Send usage/configuration questions or feature requests to: | May 05 20:47:32 | https://github.com/dani-garcia/vaultwarden/discussions or | May 05 20:47:32 | https://vaultwarden.discourse.group/ | May 05 20:47:32 | Report suspected bugs/issues in the software itself at: | May 05 20:47:32 | https://github.com/dani-garcia/vaultwarden/issues/new | May 05 20:47:32 \--------------------------------------------------------------------/ May 05 20:47:32 2026-05-06T03:47:32Z May 05 20:47:32 [INFO] Using saved config from `/app/data/config.json` for configuration. May 05 20:47:32 2026-05-06T03:47:32Z May 05 20:47:32 [2026-05-06 03:47:32.167][panic][ERROR] thread 'main' panicked at 'Error running migrations: QueryError(DieselMigrationName { name: "2026-03-09-005927_add_archives", version: MigrationVersion("20260309005927") }, DatabaseError(Unknown, "Referencing column 'user_uuid' and referenced column 'uuid' in foreign key constraint 'archives_ibfk_1' are incompatible."))': src/db/mod.rs:501 May 05 20:47:32 0: vaultwarden::init_logging::{{closure}} May 05 20:47:32 1: std::panicking::panic_with_hook May 05 20:47:32 2: std::panicking::panic_handler::{closure#0} May 05 20:47:32 3: std::sys::backtrace::__rust_end_short_backtrace::<std::panicking::panic_handler::{closure#0}, !> May 05 20:47:32 4: __rustc::rust_begin_unwind May 05 20:47:32 5: core::panicking::panic_fmt May 05 20:47:32 6: core::result::unwrap_failed May 05 20:47:32 7: vaultwarden::db::DbPool::from_config May 05 20:47:32 8: vaultwarden::main::{{closure}} May 05 20:47:32 9: vaultwarden::main May 05 20:47:32 10: std::sys::backtrace::__rust_begin_short_backtrace May 05 20:47:32 11: main May 05 20:47:32 12: <unknown> May 05 20:47:32 13: __libc_start_main May 05 20:47:32 14: _startAny ideas on this one?
-
-
Same as https://github.com/dani-garcia/vaultwarden/issues/7182 and https://github.com/dani-garcia/vaultwarden/discussions/7183 which points to some charset issues .
-
Can you check the encoding of the database and also the tables?
In the web terminal, first get the database name:
echo $CLOUDRON_MYSQL_DATABASEThen, click the mysql button above and press enter. Replace DB_NAME_HERE . You should get utf8mb4
mysql> SELECT SCHEMA_NAME, DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = 'DB_NAME_HERE'; +------------------+----------------------------+------------------------+ | SCHEMA_NAME | DEFAULT_CHARACTER_SET_NAME | DEFAULT_COLLATION_NAME | +------------------+----------------------------+------------------------+ | fb30d5a9f5fd3620 | utf8mb4 | utf8mb4_unicode_ci | +------------------+----------------------------+------------------------+Then, check all the tables.
mysql> SELECT TABLE_NAME, TABLE_TYPE, ENGINE, TABLE_COLLATION FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'fb30d5a9f5fd3620' ORDER BY TABLE_NAME; +----------------------------+------------+--------+--------------------+ | TABLE_NAME | TABLE_TYPE | ENGINE | TABLE_COLLATION | +----------------------------+------------+--------+--------------------+ | __diesel_schema_migrations | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | archives | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | attachments | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | auth_requests | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | ciphers | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | ciphers_collections | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | collections | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | collections_groups | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | devices | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | emergency_access | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | event | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | favorites | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | folders | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | folders_ciphers | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | groups | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | groups_users | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | invitations | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | org_policies | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | organization_api_key | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | organizations | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | sends | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | sso_auth | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | sso_users | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | twofactor | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | twofactor_duo_ctx | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | twofactor_incomplete | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | users | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | users_collections | BASE TABLE | InnoDB | utf8mb4_unicode_ci | | users_organizations | BASE TABLE | InnoDB | utf8mb4_unicode_ci | +----------------------------+------------+--------+--------------------+ 29 rows in set (0.01 sec)If the table encoding is not the above, then first take a backup of the app and then follow the instructions at https://github.com/dani-garcia/vaultwarden/wiki/Using-the-MariaDB-(MySQL)-Backend#foreign-key-errors-collation-and-charset
-
This seems to fix the issue indeed - At least from my side, there was a table collection charset mismatch.
The other question is how it came to be. -
Same problem here. Restored to 1.24.4 and stopped automatic updates.
-
I also had a not responding app and have reverted. Guess I need to look at that guide...
-
@jdaviescoates @joseph Thanks for your advice. I followed this guide: https://github.com/dani-garcia/vaultwarden/wiki/Using-the-MariaDB-(MySQL)-Backend#foreign-key-errors-collation-and-charset and problem now is fixed.
thanks a lot
-
The above posted link to the GitHub wiki seems to be the step by step instruction. Which is the part where you don't get forward?
-
Hello @d19dotca @teiluj @ikalou @p44 @jdaviescoates @betabreak @jayonrails
This issue was discussed before, and I did create a handy script to fix the issue.
Please see: https://forum.cloudron.io/topic/14812/vaultwarden-fails-to-start-after-update-db-migration-error-sso/24?_=1778581136537I have also merged this topic into the original topic so there is no duplicate.
-
J james referenced this topic on
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login