Vaultwarden error after image upgrade: "Referencing column 'user_uuid' and referenced column 'uuid' in foreign key constraint 'archives_ibfk_1' are incompatible."

[d19dotca]

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: _start

Any ideas on this one?

[Teiluj]

I can confirm I am seeing the same since yesterday and the package update from 1.24.4 to 1.25
The app then becomes "not Responding" with the error mentioned aboved by @d19dotca

Reverting to previous version restore functionalities/access indeed.

[ikalou]

Same here, I disabled automatic updates and reverted to 1.24.4.

[joseph]

Mine seems to have updated fine

[joseph]

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 .

[joseph]

Can you check the encoding of the database and also the tables?

In the web terminal, first get the database name:

echo $CLOUDRON_MYSQL_DATABASE

Then, 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

[Teiluj]

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.

[joseph]

@Teiluj this was a bug in vaultwarden a while go (which is why they maintain a wiki article on how to fix it up). https://github.com/search?q=repo%3Adani-garcia%2Fvaultwarden charset&type=issues

[p44]

Same problem here. Restored to 1.24.4 and stopped automatic updates.

[jdaviescoates]

I also had a not responding app and have reverted. Guess I need to look at that guide...