[GH-ISSUE #6611] Crash loop: Referencing column 'user_uuid' and referenced column 'uuid' in foreign key constraint 'sso_users_ibfk_1' are incompatible. #2484

New issue

Closed

opened 2026-03-03 02:18:47 +03:00 by kerem · 14 comments

kerem commented 2026-03-03 02:18:47 +03:00

Owner

Copy link

Originally created by @pro-to-co-ls on GitHub (Dec 28, 2025).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/6611

Prerequisites

• I have searched the existing Closed AND Open Issues AND Discussions
• I have searched and read the documentation

Vaultwarden Support String

Its crashing

Vaultwarden Build Version

v1.35.0

Deployment method

Official Container Image

Custom deployment method

No response

Reverse Proxy

traefik

Host/Server Operating System

Linux

Operating System Version

Debian

Clients

Web Vault

Client Version

No response

Steps To Reproduce

Upgraded to the latest version and getting:

[2025-12-28 13:12:30.116][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
   0: vaultwarden::init_logging::{{closure}}
   1: std::panicking::panic_with_hook
   2: std::panicking::panic_handler::{{closure}}
   3: std::sys::backtrace::__rust_end_short_backtrace
   4: __rustc::rust_begin_unwind
   5: core::panicking::panic_fmt
   6: core::result::unwrap_failed
   7: vaultwarden::db::DbPool::from_config
   8: vaultwarden::main::{{closure}}
   9: vaultwarden::main
  10: std::sys::backtrace::__rust_begin_short_backtrace
  11: main

Expected Result

it should not crash

Actual Result

see error above

Logs

Screenshots or Videos

No response

Additional Context

No response

Originally created by @pro-to-co-ls on GitHub (Dec 28, 2025). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/6611 ### Prerequisites - [x] I have searched the existing **Closed _AND_ Open** [Issues](https://github.com/dani-garcia/vaultwarden/issues?q=is%3Aissue%20) **_AND_** [Discussions](https://github.com/dani-garcia/vaultwarden/discussions?discussions_q=) - [x] I have searched and read the [documentation](https://github.com/dani-garcia/vaultwarden/wiki/) ### Vaultwarden Support String Its crashing ### Vaultwarden Build Version v1.35.0 ### Deployment method Official Container Image ### Custom deployment method _No response_ ### Reverse Proxy traefik ### Host/Server Operating System Linux ### Operating System Version Debian ### Clients Web Vault ### Client Version _No response_ ### Steps To Reproduce Upgraded to the latest version and getting: ``` [2025-12-28 13:12:30.116][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 0: vaultwarden::init_logging::{{closure}} 1: std::panicking::panic_with_hook 2: std::panicking::panic_handler::{{closure}} 3: std::sys::backtrace::__rust_end_short_backtrace 4: __rustc::rust_begin_unwind 5: core::panicking::panic_fmt 6: core::result::unwrap_failed 7: vaultwarden::db::DbPool::from_config 8: vaultwarden::main::{{closure}} 9: vaultwarden::main 10: std::sys::backtrace::__rust_begin_short_backtrace 11: main ``` ### Expected Result it should not crash ### Actual Result see error above ### Logs ```text ``` ### Screenshots or Videos _No response_ ### Additional Context _No response_

kerem 2026-03-03 02:18:47 +03:00

• closed this issue
• added the
  bug
  label

kerem commented 2026-03-03 02:18:48 +03:00

Author

Owner

Copy link

@stefan0xC commented on GitHub (Dec 28, 2025):

You neither provided a support string nor did you search for existing issues! Otherwise you might have found https://github.com/dani-garcia/vaultwarden/issues/6602#issuecomment-3694436267 or https://github.com/dani-garcia/vaultwarden/discussions/6603

<!-- gh-comment-id:3694751942 --> @stefan0xC commented on GitHub (Dec 28, 2025): You neither provided a support string nor did you search for existing issues! Otherwise you might have found https://github.com/dani-garcia/vaultwarden/issues/6602#issuecomment-3694436267 or https://github.com/dani-garcia/vaultwarden/discussions/6603

kerem commented 2026-03-03 02:18:48 +03:00

Author

Owner

Copy link

@pro-to-co-ls commented on GitHub (Dec 28, 2025):

@stefan0xC if you notice the error I posted is different from the ones you linked.

Also I can not provide a support string if its crash looping.

(I also don't understand the hostility and why this should not be fixed at the root cause - like ensuring tables are created correctly)

<!-- gh-comment-id:3694754881 --> @pro-to-co-ls commented on GitHub (Dec 28, 2025): @stefan0xC if you notice the error I posted is different from the ones you linked. Also I can not provide a support string if its crash looping. (I also don't understand the hostility and why this should not be fixed at the root cause - like ensuring tables are created correctly)

kerem commented 2026-03-03 02:18:48 +03:00

Author

Owner

Copy link

@stefan0xC commented on GitHub (Dec 28, 2025):

Can you still make sure that the collation and charset of your database and tables are correctly set? Or are you not using MySQL or MariaDB?

<!-- gh-comment-id:3694757252 --> @stefan0xC commented on GitHub (Dec 28, 2025): Can you still [make sure that the collation and charset of your database and tables](https://github.com/dani-garcia/vaultwarden/wiki/Using-the-MariaDB-%28MySQL%29-Backend#foreign-key-errors-collation-and-charset) are correctly set? Or are you not using MySQL or MariaDB?

kerem commented 2026-03-03 02:18:48 +03:00

Author

Owner

Copy link

@williamdes commented on GitHub (Dec 28, 2025):

I have this in my logs

[2025-12-28 11:06:15.366][panic][ERROR] thread 'main' panicked at 'Error running migrations: QueryError(DieselMigrationName { name: "2024-03-06-170000_add_sso_users", version: MigrationVersion("20240306170000") }, DatabaseError(Unknown, "Can't create table `vaultwarden`.`sso_users` (errno: 150 \"Foreign key constraint is incorrectly formed\")"))': src/db/mod.rs:505
   0: vaultwarden::init_logging::{{closure}}
   1: std::panicking::panic_with_hook
   2: std::panicking::panic_handler::{{closure}}
   3: std::sys::backtrace::__rust_end_short_backtrace
   4: __rustc::rust_begin_unwind
   5: core::panicking::panic_fmt
   6: core::result::unwrap_failed
   7: vaultwarden::db::DbPool::from_config
   8: vaultwarden::main::{{closure}}
   9: vaultwarden::main
  10: std::sys::backtrace::__rust_begin_short_backtrace
  11: main
  12: <unknown>
  13: __libc_start_main
  14: _start

Probably related in some way

<!-- gh-comment-id:3694985708 --> @williamdes commented on GitHub (Dec 28, 2025): I have this in my logs ``` [2025-12-28 11:06:15.366][panic][ERROR] thread 'main' panicked at 'Error running migrations: QueryError(DieselMigrationName { name: "2024-03-06-170000_add_sso_users", version: MigrationVersion("20240306170000") }, DatabaseError(Unknown, "Can't create table `vaultwarden`.`sso_users` (errno: 150 \"Foreign key constraint is incorrectly formed\")"))': src/db/mod.rs:505 0: vaultwarden::init_logging::{{closure}} 1: std::panicking::panic_with_hook 2: std::panicking::panic_handler::{{closure}} 3: std::sys::backtrace::__rust_end_short_backtrace 4: __rustc::rust_begin_unwind 5: core::panicking::panic_fmt 6: core::result::unwrap_failed 7: vaultwarden::db::DbPool::from_config 8: vaultwarden::main::{{closure}} 9: vaultwarden::main 10: std::sys::backtrace::__rust_begin_short_backtrace 11: main 12: <unknown> 13: __libc_start_main 14: _start ``` Probably related in some way

kerem commented 2026-03-03 02:18:48 +03:00

Author

Owner

Copy link

@SuperGaleb commented on GitHub (Dec 29, 2025):

Same problem on my installation. This is definitely related to character set being incorrectly set at the start (few years ago).
Reverting to: image: vaultwarden/server:1.34.3 and everything is back online again.

Database changed
MariaDB [vaultwarden]> SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = "vaultwarden";
+----------------------------+------------------------+
| DEFAULT_CHARACTER_SET_NAME | DEFAULT_COLLATION_NAME |
+----------------------------+------------------------+
| utf8mb4 | utf8mb4_unicode_ci |
+----------------------------+------------------------+
1 row in set (0.001 sec)

MariaDB [vaultwarden]> SELECT CHARACTER_SET_NAME, COLLATION_NAME FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = "vaultwarden" AND CHARACTER_SET_NAME IS NOT NULL;
+--------------------+-----------------------+
| CHARACTER_SET_NAME | COLLATION_NAME |
+--------------------+-----------------------+
| utf8mb4 | utf8mb4_general_ci |
| utf8mb4 | utf8mb4_general_ci |
| utf8mb4 | utf8mb4_general_ci |
| utf8mb4 | utf8mb4_general_ci |
| utf8mb4 | utf8mb4_general_ci |

However I am not able to change it as per instructions (https://github.com/dani-garcia/vaultwarden/wiki/Using-the-MariaDB-%28MySQL%29-Backend#foreign-key-errors-collation-and-charset).

Setting SET FOREIGN_KEY_CHECKS = 0; and/or SET GLOBAL FOREIGN_KEY_CHECKS=0;
does not work for me.

MariaDB [vaultwarden]> SET foreign_key_checks = 0;
Query OK, 0 rows affected (0.000 sec)

MariaDB [vaultwarden]> ALTER TABLE users_collections CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ERROR 1832 (HY000): Cannot change column 'user_uuid': used in a foreign key constraint 'users_collections_ibfk_1'
MariaDB [vaultwarden]> ALTER TABLE folders CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ERROR 1833 (HY000): Cannot change column 'uuid': used in a foreign key constraint 'folders_ciphers_ibfk_2' of table 'vaultwarden.folders_ciphers'
MariaDB [vaultwarden]> ALTER TABLE organization_api_key CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ERROR 1832 (HY000): Cannot change column 'org_uuid': used in a foreign key constraint 'organization_api_key_ibfk_1'
MariaDB [vaultwarden]> ALTER TABLE groups CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ERROR 1833 (HY000): Cannot change column 'uuid': used in a foreign key constraint 'collections_groups_ibfk_2' of table 'vaultwarden.collections_groups'
MariaDB [vaultwarden]> ALTER TABLE sso_nonce CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
Query OK, 0 rows affected (0.030 sec)
Records: 0 Duplicates: 0 Warnings: 0.....

Only permanent DROP FOREIGN KEY works. Still can not work out how to add back ALTER TABLE child_table ADD CONSTRAINT fk_name FOREIGN KEY (column_name) REFERENCES later.

ALTER TABLE favorites DROP FOREIGN KEY favorites_ibfk_1;
ALTER TABLE favorites DROP FOREIGN KEY favorites_ibfk_2;
.....

<!-- gh-comment-id:3695365157 --> @SuperGaleb commented on GitHub (Dec 29, 2025): Same problem on my installation. This is definitely related to character set being incorrectly set at the start (few years ago). Reverting to: image: vaultwarden/server:1.34.3 and everything is back online again. Database changed MariaDB [vaultwarden]> SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = "vaultwarden"; +----------------------------+------------------------+ | DEFAULT_CHARACTER_SET_NAME | DEFAULT_COLLATION_NAME | +----------------------------+------------------------+ | utf8mb4 | utf8mb4_unicode_ci | +----------------------------+------------------------+ 1 row in set (0.001 sec) MariaDB [vaultwarden]> SELECT CHARACTER_SET_NAME, COLLATION_NAME FROM information_schema.`COLUMNS` WHERE TABLE_SCHEMA = "vaultwarden" AND CHARACTER_SET_NAME IS NOT NULL; +--------------------+-----------------------+ | CHARACTER_SET_NAME | COLLATION_NAME | +--------------------+-----------------------+ | utf8mb4 | utf8mb4_general_ci | | utf8mb4 | utf8mb4_general_ci | | utf8mb4 | utf8mb4_general_ci | | utf8mb4 | utf8mb4_general_ci | | utf8mb4 | utf8mb4_general_ci | However I am not able to change it as per instructions (https://github.com/dani-garcia/vaultwarden/wiki/Using-the-MariaDB-%28MySQL%29-Backend#foreign-key-errors-collation-and-charset). **Setting SET FOREIGN_KEY_CHECKS = 0; and/or SET GLOBAL FOREIGN_KEY_CHECKS=0; does not work for me.** MariaDB [vaultwarden]> SET foreign_key_checks = 0; Query OK, 0 rows affected (0.000 sec) MariaDB [vaultwarden]> ALTER TABLE `users_collections` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ERROR 1832 (HY000): Cannot change column 'user_uuid': used in a foreign key constraint 'users_collections_ibfk_1' MariaDB [vaultwarden]> ALTER TABLE `folders` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ERROR 1833 (HY000): Cannot change column 'uuid': used in a foreign key constraint 'folders_ciphers_ibfk_2' of table 'vaultwarden.folders_ciphers' MariaDB [vaultwarden]> ALTER TABLE `organization_api_key` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ERROR 1832 (HY000): Cannot change column 'org_uuid': used in a foreign key constraint 'organization_api_key_ibfk_1' MariaDB [vaultwarden]> ALTER TABLE `groups` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ERROR 1833 (HY000): Cannot change column 'uuid': used in a foreign key constraint 'collections_groups_ibfk_2' of table 'vaultwarden.collections_groups' MariaDB [vaultwarden]> ALTER TABLE `sso_nonce` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; Query OK, 0 rows affected (0.030 sec) Records: 0 Duplicates: 0 Warnings: 0..... Only permanent DROP FOREIGN KEY works. Still can not work out how to add back ALTER TABLE child_table ADD CONSTRAINT fk_name FOREIGN KEY (column_name) REFERENCES later. ALTER TABLE favorites DROP FOREIGN KEY favorites_ibfk_1; ALTER TABLE favorites DROP FOREIGN KEY favorites_ibfk_2; .....

kerem commented 2026-03-03 02:18:48 +03:00

Author

Owner

Copy link

@3XC1T3D commented on GitHub (Dec 29, 2025):

i backuped the vaultwarden schema. dopped the schema. modified the collation in the dump file to utf8mb4_unicode_ci and imported the data again. now the error is gone.

<!-- gh-comment-id:3695800800 --> @3XC1T3D commented on GitHub (Dec 29, 2025): i backuped the vaultwarden schema. dopped the schema. modified the collation in the dump file to **utf8mb4_unicode_ci** and imported the data again. now the error is gone.

kerem commented 2026-03-03 02:18:48 +03:00

Author

Owner

Copy link

@kimpenhaus commented on GitHub (Dec 29, 2025):

@SuperGaleb I had the exactly same - I managed to get it working with this sql:

SET foreign_key_checks = 0;

ALTER TABLE `auth_requests`
  DROP FOREIGN KEY `auth_requests_ibfk_1`,
  DROP FOREIGN KEY `auth_requests_ibfk_2`;

ALTER TABLE `users`
  CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

ALTER TABLE `organizations`
  CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

ALTER TABLE `auth_requests`
  CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

ALTER TABLE `auth_requests`
  ADD CONSTRAINT `auth_requests_ibfk_1`
    FOREIGN KEY (`user_uuid`) REFERENCES `users` (`uuid`),
  ADD CONSTRAINT `auth_requests_ibfk_2`
    FOREIGN KEY (`organization_uuid`) REFERENCES `organizations` (`uuid`);

SET foreign_key_checks = 1;

when all tables were converted I could start the container with no issues.

<!-- gh-comment-id:3697169656 --> @kimpenhaus commented on GitHub (Dec 29, 2025): @SuperGaleb I had the exactly same - I managed to get it working with this sql: ```sql SET foreign_key_checks = 0; ALTER TABLE `auth_requests` DROP FOREIGN KEY `auth_requests_ibfk_1`, DROP FOREIGN KEY `auth_requests_ibfk_2`; ALTER TABLE `users` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `organizations` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `auth_requests` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `auth_requests` ADD CONSTRAINT `auth_requests_ibfk_1` FOREIGN KEY (`user_uuid`) REFERENCES `users` (`uuid`), ADD CONSTRAINT `auth_requests_ibfk_2` FOREIGN KEY (`organization_uuid`) REFERENCES `organizations` (`uuid`); SET foreign_key_checks = 1; ``` when all tables were converted I could start the container with no issues.

kerem commented 2026-03-03 02:18:48 +03:00

Author

Owner

Copy link

@SuperGaleb commented on GitHub (Dec 29, 2025):

@SuperGaleb I had the exactly same - I managed to get it working with this sql:

SET foreign_key_checks = 0;

ALTER TABLE auth_requests
DROP FOREIGN KEY auth_requests_ibfk_1,
DROP FOREIGN KEY auth_requests_ibfk_2;

ALTER TABLE users
CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

ALTER TABLE organizations
CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

ALTER TABLE auth_requests
CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

ALTER TABLE auth_requests
ADD CONSTRAINT auth_requests_ibfk_1
FOREIGN KEY (user_uuid) REFERENCES users (uuid),
ADD CONSTRAINT auth_requests_ibfk_2
FOREIGN KEY (organization_uuid) REFERENCES organizations (uuid);

SET foreign_key_checks = 1;
when all tables were converted I could start the container with no issues.

Unfortunately no luck. This is more/less what I was trying yesterday.
Modifying collation in the dump file to utf8mb4_unicode_ci and importing the data back as 3XC1T3D suggested worked .
Thank you.

MariaDB [vaultwarden]> SET foreign_key_checks = 0;
Query OK, 0 rows affected (0.000 sec)

MariaDB [vaultwarden]>
MariaDB [vaultwarden]> ALTER TABLE auth_requests
-> DROP FOREIGN KEY auth_requests_ibfk_1,
-> DROP FOREIGN KEY auth_requests_ibfk_2;
Query OK, 0 rows affected (0.028 sec)
Records: 0 Duplicates: 0 Warnings: 0

MariaDB [vaultwarden]>
MariaDB [vaultwarden]> ALTER TABLE users
-> CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ERROR 1833 (HY000): Cannot change column 'uuid': used in a foreign key constraint 'ciphers_ibfk_1' of table 'vaultwarden.ciphers'
MariaDB [vaultwarden]>
MariaDB [vaultwarden]> ALTER TABLE organizations
-> CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ERROR 1833 (HY000): Cannot change column 'uuid': used in a foreign key constraint 'ciphers_ibfk_2' of table 'vaultwarden.ciphers'
MariaDB [vaultwarden]>
MariaDB [vaultwarden]> ALTER TABLE auth_requests
-> CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
Query OK, 0 rows affected (0.033 sec)
Records: 0 Duplicates: 0 Warnings: 0

MariaDB [vaultwarden]>
MariaDB [vaultwarden]> ALTER TABLE auth_requests
-> ADD CONSTRAINT auth_requests_ibfk_1
-> FOREIGN KEY (user_uuid) REFERENCES users (uuid),
-> ADD CONSTRAINT auth_requests_ibfk_2
-> FOREIGN KEY (organization_uuid) REFERENCES organizations (uuid);
ERROR 1822 (HY000): Failed to add the foreign key constraint. Missing index for constraint 'auth_requests_ibfk_1' in the referenced table 'users'
MariaDB [vaultwarden]>
MariaDB [vaultwarden]> SET foreign_key_checks = 1;
Query OK, 0 rows affected (0.000 sec)

<!-- gh-comment-id:3697504528 --> @SuperGaleb commented on GitHub (Dec 29, 2025): > [@SuperGaleb](https://github.com/SuperGaleb) I had the exactly same - I managed to get it working with this sql: > > SET foreign_key_checks = 0; > > ALTER TABLE `auth_requests` > DROP FOREIGN KEY `auth_requests_ibfk_1`, > DROP FOREIGN KEY `auth_requests_ibfk_2`; > > ALTER TABLE `users` > CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; > > ALTER TABLE `organizations` > CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; > > ALTER TABLE `auth_requests` > CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; > > ALTER TABLE `auth_requests` > ADD CONSTRAINT `auth_requests_ibfk_1` > FOREIGN KEY (`user_uuid`) REFERENCES `users` (`uuid`), > ADD CONSTRAINT `auth_requests_ibfk_2` > FOREIGN KEY (`organization_uuid`) REFERENCES `organizations` (`uuid`); > > SET foreign_key_checks = 1; > when all tables were converted I could start the container with no issues. Unfortunately no luck. This is more/less what I was trying yesterday. Modifying collation in the dump file to utf8mb4_unicode_ci and importing the data back as [3XC1T3D](https://github.com/3XC1T3D) suggested worked . Thank you. MariaDB [vaultwarden]> SET foreign_key_checks = 0; Query OK, 0 rows affected (0.000 sec) MariaDB [vaultwarden]> MariaDB [vaultwarden]> ALTER TABLE `auth_requests` -> DROP FOREIGN KEY `auth_requests_ibfk_1`, -> DROP FOREIGN KEY `auth_requests_ibfk_2`; Query OK, 0 rows affected (0.028 sec) Records: 0 Duplicates: 0 Warnings: 0 MariaDB [vaultwarden]> MariaDB [vaultwarden]> ALTER TABLE `users` -> CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ERROR 1833 (HY000): Cannot change column 'uuid': used in a foreign key constraint 'ciphers_ibfk_1' of table 'vaultwarden.ciphers' MariaDB [vaultwarden]> MariaDB [vaultwarden]> ALTER TABLE `organizations` -> CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ERROR 1833 (HY000): Cannot change column 'uuid': used in a foreign key constraint 'ciphers_ibfk_2' of table 'vaultwarden.ciphers' MariaDB [vaultwarden]> MariaDB [vaultwarden]> ALTER TABLE `auth_requests` -> CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; Query OK, 0 rows affected (0.033 sec) Records: 0 Duplicates: 0 Warnings: 0 MariaDB [vaultwarden]> MariaDB [vaultwarden]> ALTER TABLE `auth_requests` -> ADD CONSTRAINT `auth_requests_ibfk_1` -> FOREIGN KEY (`user_uuid`) REFERENCES `users` (`uuid`), -> ADD CONSTRAINT `auth_requests_ibfk_2` -> FOREIGN KEY (`organization_uuid`) REFERENCES `organizations` (`uuid`); ERROR 1822 (HY000): Failed to add the foreign key constraint. Missing index for constraint 'auth_requests_ibfk_1' in the referenced table 'users' MariaDB [vaultwarden]> MariaDB [vaultwarden]> SET foreign_key_checks = 1; Query OK, 0 rows affected (0.000 sec)

kerem commented 2026-03-03 02:18:49 +03:00

Author

Owner

Copy link

@SuperGaleb commented on GitHub (Dec 29, 2025):

i backuped the vaultwarden schema. dopped the schema. modified the collation in the dump file to utf8mb4_unicode_ci and imported the data again. now the error is gone.

Worked like a charm. Thank you !!!

<!-- gh-comment-id:3697505854 --> @SuperGaleb commented on GitHub (Dec 29, 2025): > i backuped the vaultwarden schema. dopped the schema. modified the collation in the dump file to **utf8mb4_unicode_ci** and imported the data again. now the error is gone. Worked like a charm. Thank you !!!

kerem commented 2026-03-03 02:18:49 +03:00

Author

Owner

Copy link

@SuperGaleb commented on GitHub (Dec 29, 2025):

For those who still have same problem, this is how I fixed it. Thanks to 3XC1T3D for this idea.

First, generate a SQL dump using mariadb-dump with appropriate flags (change container name and db-passwd to your setup):

docker exec -it <container_name> mariadb-dump -u 'root' -p'<your_db-passwd>' \
       --single-transaction \
       --add-drop-table \
       --lock-tables \
       --complete-insert \
       --extended-insert \
       vaultwarden \
       > /home/supergaleb/opt/db-dumps/vaultwarden.sql

Create a copy of the dump file and use sed to replace all instances of existing character set and collation definitions with utf8mb4 and utf8mb4_unicode_ci.

cp vaultwarden.sql vw.sql
sed -i 's/utf8mb4_unicode_cimb4/utf8mb4_unicode_ci/g' vw.sql
sed -i 's/utf8mb4_general_ci/utf8mb4_unicode_ci/g' vw.sql

Before importing, ensure the target database is recreated with the correct character set:

docker exec -i <container_name> mariadb -u 'root' -p<your_db-passwd>' -e "DROP DATABASE IF EXISTS vaultwarden";
docker exec -i <container_name> mariadb -u 'root' -p<your_db-passwd>' -e "CREATE DATABASE vaultwarden CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci";

Import the modified dump:
docker exec -i <container_name> mariadb -u 'root' -p<your_db-passwd>' vaultwarden < /home/supergaleb/opt/db-dumps/vw.sql

Verify the settings (log into your container/mariadb first):

SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = "vaultwarden";
SELECT CHARACTER_SET_NAME, COLLATION_NAME FROM information_schema.`COLUMNS` WHERE TABLE_SCHEMA = "vaultwarden" AND CHARACTER_SET_NAME IS NOT NULL;

<!-- gh-comment-id:3697530296 --> @SuperGaleb commented on GitHub (Dec 29, 2025): For those who still have same problem, this is how I fixed it. Thanks to 3XC1T3D for this idea. First, generate a SQL dump using mariadb-dump with appropriate flags (change container name and db-passwd to your setup): ``` docker exec -it <container_name> mariadb-dump -u 'root' -p'<your_db-passwd>' \ --single-transaction \ --add-drop-table \ --lock-tables \ --complete-insert \ --extended-insert \ vaultwarden \ > /home/supergaleb/opt/db-dumps/vaultwarden.sql ``` Create a copy of the dump file and use sed to replace all instances of existing character set and collation definitions with utf8mb4 and utf8mb4_unicode_ci. ``` cp vaultwarden.sql vw.sql sed -i 's/utf8mb4_unicode_cimb4/utf8mb4_unicode_ci/g' vw.sql sed -i 's/utf8mb4_general_ci/utf8mb4_unicode_ci/g' vw.sql ``` Before importing, ensure the target database is recreated with the correct character set: ``` docker exec -i <container_name> mariadb -u 'root' -p<your_db-passwd>' -e "DROP DATABASE IF EXISTS vaultwarden"; docker exec -i <container_name> mariadb -u 'root' -p<your_db-passwd>' -e "CREATE DATABASE vaultwarden CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci"; ``` Import the modified dump: `docker exec -i <container_name> mariadb -u 'root' -p<your_db-passwd>' vaultwarden < /home/supergaleb/opt/db-dumps/vw.sql` Verify the settings (log into your container/mariadb first): ``` SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = "vaultwarden"; SELECT CHARACTER_SET_NAME, COLLATION_NAME FROM information_schema.`COLUMNS` WHERE TABLE_SCHEMA = "vaultwarden" AND CHARACTER_SET_NAME IS NOT NULL; ```

kerem commented 2026-03-03 02:18:49 +03:00

Author

Owner

Copy link

@DorianCoding commented on GitHub (Dec 30, 2025):

i backuped the vaultwarden schema. dopped the schema. modified the collation in the dump file to utf8mb4_unicode_ci and imported the data again. now the error is gone.

Worked like a charm. Thank you !!!

I have the same problem, dumping the database as stated works, as long as the character set by default of the database is also changed accordingly.

<!-- gh-comment-id:3700539191 --> @DorianCoding commented on GitHub (Dec 30, 2025): > > i backuped the vaultwarden schema. dopped the schema. modified the collation in the dump file to **utf8mb4_unicode_ci** and imported the data again. now the error is gone. > > Worked like a charm. Thank you !!! I have the same problem, dumping the database as stated works, as long as the character set by default of the database is also changed accordingly.

kerem commented 2026-03-03 02:18:49 +03:00

Author

Owner

Copy link

@ballerbude commented on GitHub (Dec 30, 2025):

For those who still have same problem, this is how I fixed it. Thanks to 3XC1T3D for this idea.

First, generate a SQL dump using mariadb-dump with appropriate flags (change container name and db-passwd to your setup):

docker exec -it <container_name> mariadb-dump -u 'root' -p'<your_db-passwd>' \
       --single-transaction \
       --add-drop-table \
       --lock-tables \
       --complete-insert \
       --extended-insert \
       vaultwarden \
       > /home/supergaleb/opt/db-dumps/vaultwarden.sql

Create a copy of the dump file and use sed to replace all instances of existing character set and collation definitions with utf8mb4 and utf8mb4_unicode_ci.

cp vaultwarden.sql vw.sql
sed -i 's/utf8mb4_unicode_cimb4/utf8mb4_unicode_ci/g' vw.sql
sed -i 's/utf8mb4_general_ci/utf8mb4_unicode_ci/g' vw.sql

Before importing, ensure the target database is recreated with the correct character set:

docker exec -i <container_name> mariadb -u 'root' -p<your_db-passwd>' -e "DROP DATABASE IF EXISTS vaultwarden";
docker exec -i <container_name> mariadb -u 'root' -p<your_db-passwd>' -e "CREATE DATABASE vaultwarden CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci";

Import the modified dump: docker exec -i <container_name> mariadb -u 'root' -p<your_db-passwd>' vaultwarden < /home/supergaleb/opt/db-dumps/vw.sql

Verify the settings (log into your container/mariadb first):

SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = "vaultwarden";
SELECT CHARACTER_SET_NAME, COLLATION_NAME FROM information_schema.`COLUMNS` WHERE TABLE_SCHEMA = "vaultwarden" AND CHARACTER_SET_NAME IS NOT NULL;

This was a great help. Everything is up and running again. Thank you!

<!-- gh-comment-id:3700849991 --> @ballerbude commented on GitHub (Dec 30, 2025): > For those who still have same problem, this is how I fixed it. Thanks to 3XC1T3D for this idea. > > First, generate a SQL dump using mariadb-dump with appropriate flags (change container name and db-passwd to your setup): > > ``` > docker exec -it <container_name> mariadb-dump -u 'root' -p'<your_db-passwd>' \ > --single-transaction \ > --add-drop-table \ > --lock-tables \ > --complete-insert \ > --extended-insert \ > vaultwarden \ > > /home/supergaleb/opt/db-dumps/vaultwarden.sql > ``` > > Create a copy of the dump file and use sed to replace all instances of existing character set and collation definitions with utf8mb4 and utf8mb4_unicode_ci. > > ``` > cp vaultwarden.sql vw.sql > sed -i 's/utf8mb4_unicode_cimb4/utf8mb4_unicode_ci/g' vw.sql > sed -i 's/utf8mb4_general_ci/utf8mb4_unicode_ci/g' vw.sql > ``` > > Before importing, ensure the target database is recreated with the correct character set: > > ``` > docker exec -i <container_name> mariadb -u 'root' -p<your_db-passwd>' -e "DROP DATABASE IF EXISTS vaultwarden"; > docker exec -i <container_name> mariadb -u 'root' -p<your_db-passwd>' -e "CREATE DATABASE vaultwarden CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci"; > ``` > > Import the modified dump: `docker exec -i <container_name> mariadb -u 'root' -p<your_db-passwd>' vaultwarden < /home/supergaleb/opt/db-dumps/vw.sql` > > Verify the settings (log into your container/mariadb first): > > ``` > SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = "vaultwarden"; > SELECT CHARACTER_SET_NAME, COLLATION_NAME FROM information_schema.`COLUMNS` WHERE TABLE_SCHEMA = "vaultwarden" AND CHARACTER_SET_NAME IS NOT NULL; > ``` This was a great help. Everything is up and running again. Thank you!

kerem commented 2026-03-03 02:18:49 +03:00

Author

Owner

Copy link

@BlackDex commented on GitHub (Jan 8, 2026):

(I also don't understand the hostility and why this should not be fixed at the root cause - like ensuring tables are created correctly)

If tables are created using a wrong schema, encoding or collate, that isn't something we can fix afterwards.

Ill see if we can somehow fix this to be a default during creation and connection, but that still doesn't fix the tables it self, that is something the database admin should do manually.

<!-- gh-comment-id:3725566097 --> @BlackDex commented on GitHub (Jan 8, 2026): > (I also don't understand the hostility and why this should not be fixed at the root cause - like ensuring tables are created correctly) If tables are created using a wrong schema, encoding or collate, that isn't something we can fix afterwards. Ill see if we can somehow fix this to be a default during creation and connection, but that still doesn't fix the tables it self, that is something the database admin should do manually.

kerem commented 2026-03-03 02:18:49 +03:00

Author

Owner

Copy link

@sigma2017 commented on GitHub (Jan 13, 2026):

Hello, I was using the latest vaultwarden docker image (5 month old so I suppose I had v1.34.3)
How I fixed it after docker pull vaultwarden/server:latest (All the changes were performed in mariadb. I am using bitnami/mariadb-galera 11.4.7 with wsrep_provider_version | 4.22(r216f068))

Step 1: Diagnostic Schema

USE vaultwarden;
SHOW TABLES LIKE 'sso_users';  -- Empty set (this table doesn't exists)
SHOW CREATE TABLE users\G;     -- CHARSET=latin1_swedish_ci
SELECT TABLE_NAME, TABLE_COLLATION FROM information_schema.TABLES 
WHERE TABLE_SCHEMA='vaultwarden' AND TABLE_TYPE='BASE TABLE';

→ 26/28 latin1 tables.

Step 2: Script Convert (most of the tables)

SET foreign_key_checks=0;
ALTER TABLE `attachments` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `auth_requests` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `ciphers` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `ciphers_collections` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `collections` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `collections_groups` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `devices` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `emergency_access` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `event` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `favorites` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `folders` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `folders_ciphers` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `groups` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `groups_users` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `invitations` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `organizations` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `organization_api_key` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `org_policies` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `sends` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `twofactor` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `twofactor_duo_ctx` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `twofactor_incomplete` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `users` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `users_collections` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `users_organizations` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `__diesel_schema_migrations` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
SET foreign_key_checks=1;

The following 3 tables can not be converted, and tried again only for these tables:

ALTER TABLE `auth_requests` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
  ERROR 1832 (HY000): Cannot change column 'user_uuid': used in a foreign key constraint 'auth_requests_ibfk_1'
ALTER TABLE `organizations` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
  ERROR 1833 (HY000): Cannot change column 'uuid': used in a foreign key constraint 'auth_requests_ibfk_2' of table 'vaultwarden.auth_requests'
ALTER TABLE `users` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
  ERROR 1833 (HY000): Cannot change column 'uuid': used in a foreign key constraint 'auth_requests_ibfk_1' of table 'vaultwarden.auth_requests'

Step 3: Fix blocked FK blocked (auth_requests -> users/organizations)

SHOW CREATE TABLE auth_requests\G;  -- Confirm FK: auth_requests_ibfk_1/2 pe uuid

SET foreign_key_checks=0; 
SET unique_checks=0;
ALTER TABLE auth_requests DROP FOREIGN KEY auth_requests_ibfk_1;
ALTER TABLE auth_requests DROP FOREIGN KEY auth_requests_ibfk_2;
ALTER TABLE auth_requests CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE organizations CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE users CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE auth_requests ADD CONSTRAINT auth_requests_ibfk_1 
  FOREIGN KEY (user_uuid) REFERENCES users(uuid),
  ADD CONSTRAINT auth_requests_ibfk_2 
  FOREIGN KEY (organization_uuid) REFERENCES organizations(uuid);
SET foreign_key_checks=1; 
SET unique_checks=1;

Step 4: Final check:

SELECT TABLE_NAME, ENGINE, TABLE_COLLATION FROM information_schema.TABLES 
WHERE TABLE_SCHEMA = 'vaultwarden' AND TABLE_TYPE = 'BASE TABLE'
ORDER BY TABLE_NAME;

→ All utf8mb4_unicode_ci

SHOW STATUS LIKE 'wsrep%'; -- cluster_size=3, Synced, ready=ON

Pas 5: Restart & Test

On both nodes where galera is running:
docker restart bitwarden
On the node where I have nginx RP and arbiter:
docker restart garbd

Checking container status:
docker logs bitwarden

"Starting Vaultwarden" OK

I use bitwarden (docker container based on the same docker image) for more than 2 years but initially i used single mysql 5.7 node. Since last year I have created a galera cluster and moved the existing database from mysql to mariadb/galera.
Maybe my solution doesn't fit all scenarios, I wanted to mention this details to avoid confusion.
What I have explained here is exactly what I did, no more, no less.

<!-- gh-comment-id:3746635338 --> @sigma2017 commented on GitHub (Jan 13, 2026): Hello, I was using the latest vaultwarden docker image (5 month old so I suppose I had v1.34.3) How I fixed it after docker pull vaultwarden/server:latest (All the changes were performed in mariadb. I am using bitnami/mariadb-galera 11.4.7 with wsrep_provider_version | 4.22(r216f068)) Step 1: Diagnostic Schema ``` USE vaultwarden; SHOW TABLES LIKE 'sso_users'; -- Empty set (this table doesn't exists) SHOW CREATE TABLE users\G; -- CHARSET=latin1_swedish_ci SELECT TABLE_NAME, TABLE_COLLATION FROM information_schema.TABLES WHERE TABLE_SCHEMA='vaultwarden' AND TABLE_TYPE='BASE TABLE'; ``` → 26/28 latin1 tables. Step 2: Script Convert (most of the tables) ``` SET foreign_key_checks=0; ALTER TABLE `attachments` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `auth_requests` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `ciphers` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `ciphers_collections` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `collections` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `collections_groups` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `devices` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `emergency_access` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `event` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `favorites` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `folders` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `folders_ciphers` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `groups` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `groups_users` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `invitations` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `organizations` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `organization_api_key` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `org_policies` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `sends` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `twofactor` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `twofactor_duo_ctx` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `twofactor_incomplete` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `users` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `users_collections` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `users_organizations` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `__diesel_schema_migrations` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; SET foreign_key_checks=1; ``` The following 3 tables can not be converted, and tried again only for these tables: ``` ALTER TABLE `auth_requests` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ERROR 1832 (HY000): Cannot change column 'user_uuid': used in a foreign key constraint 'auth_requests_ibfk_1' ALTER TABLE `organizations` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ERROR 1833 (HY000): Cannot change column 'uuid': used in a foreign key constraint 'auth_requests_ibfk_2' of table 'vaultwarden.auth_requests' ALTER TABLE `users` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ERROR 1833 (HY000): Cannot change column 'uuid': used in a foreign key constraint 'auth_requests_ibfk_1' of table 'vaultwarden.auth_requests' ``` Step 3: Fix blocked FK blocked (auth_requests -> users/organizations) ``` SHOW CREATE TABLE auth_requests\G; -- Confirm FK: auth_requests_ibfk_1/2 pe uuid SET foreign_key_checks=0; SET unique_checks=0; ALTER TABLE auth_requests DROP FOREIGN KEY auth_requests_ibfk_1; ALTER TABLE auth_requests DROP FOREIGN KEY auth_requests_ibfk_2; ALTER TABLE auth_requests CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE organizations CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE users CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE auth_requests ADD CONSTRAINT auth_requests_ibfk_1 FOREIGN KEY (user_uuid) REFERENCES users(uuid), ADD CONSTRAINT auth_requests_ibfk_2 FOREIGN KEY (organization_uuid) REFERENCES organizations(uuid); SET foreign_key_checks=1; SET unique_checks=1; ``` Step 4: Final check: ``` SELECT TABLE_NAME, ENGINE, TABLE_COLLATION FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'vaultwarden' AND TABLE_TYPE = 'BASE TABLE' ORDER BY TABLE_NAME; ``` → All utf8mb4_unicode_ci `SHOW STATUS LIKE 'wsrep%'; -- cluster_size=3, Synced, ready=ON` Pas 5: Restart & Test On both nodes where galera is running: `docker restart bitwarden` On the node where I have nginx RP and arbiter: `docker restart garbd` Checking container status: `docker logs bitwarden` # "Starting Vaultwarden" OK I use bitwarden (docker container based on the same docker image) for more than 2 years but initially i used single mysql 5.7 node. Since last year I have created a galera cluster and moved the existing database from mysql to mariadb/galera. Maybe my solution doesn't fit all scenarios, I wanted to mention this details to avoid confusion. What I have explained here is exactly what I did, no more, no less.

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

Subscribe

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#2484

No description provided.