Error MariaDB 11.X

[madito]

Prerequisites

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

Vaultwarden Support String

Service Down

Vaultwarden Build Version

1.36

Deployment method

Manually Extracted from Container Image

Custom deployment method

No response

Reverse Proxy

nginx

Host/Server Operating System

Linux

Operating System Version

Ubuntu 24.04

Clients

Web Vault

Client Version

No response

Steps To Reproduce

Hi,

I performed a migration from one server to another, keeping the Ubuntu OS. Currently, when I start Vaultwarder version 1.36, I get a migration error. The database collation is correct (CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci). I temporarily replicated a local installation, only changing the database engine from MariaDB to MySQL, and it works correctly. It seems the problem is with MariaDB.

I deleted my database so that the database schema would be generated on the first boot. When I stop the service and restart it, the new database it just created gives the exact same error as my original database.

Versions:

1.36 Vaultwarden (extrac to docker and compile).
mariadb from 11.8.8-MariaDB, client 15.2 for debian-linux-gnu (x86_64) using EditLine wrapper
Ubuntu 24.04.4

Expected Result

Up the service.

Actual Result

[12:29:08.932 28-05-2026][panic][ERROR] thread 'main' panicked at 'Error running migrations: QueryError(DieselMigrationName { name: "2026-04-25-120000_sso_auth_binding", version: MigrationVersion("202604251 20000") }, DatabaseError(Unknown, "Duplicate column name 'binding_hash'"))': src/db/mod.rs:501
0: vaultwarden::init_logging::{{closure}}
1: std::panicking::panic_with_hook
2: std::panicking::panic_handler::{closure#0}
3: std::sys::backtrace::__rust_end_short_backtrace::<std::panicking::panic_handler::{closure#0}, !>
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:
13: __libc_start_main
14: _start

Logs

Screenshots or Videos

No response

Additional Context

No response

[jirireischig]

This problem look like similar to #7241

[blind-oracle]

The same happens for me. The binding_hash column from migration script (https://github.com/dani-garcia/vaultwarden/blob/d626ea81abf8504b7e54be14b0cfaf45134171b6/migrations/mysql/2026-04-25-120000_sso_auth_binding/up.sql) gets created:

MariaDB [bitwarden]> describe sso_auth;
+------------------+--------------+------+-----+---------------------+-------+
| Field            | Type         | Null | Key | Default             | Extra |
+------------------+--------------+------+-----+---------------------+-------+
| state            | varchar(512) | NO   | PRI | NULL                |       |
| client_challenge | text         | NO   |     | NULL                |       |
| nonce            | text         | NO   |     | NULL                |       |
| redirect_uri     | text         | NO   |     | NULL                |       |
| code_response    | text         | YES  |     | NULL                |       |
| auth_response    | text         | YES  |     | NULL                |       |
| created_at       | timestamp    | NO   |     | current_timestamp() |       |
| updated_at       | timestamp    | NO   |     | current_timestamp() |       |
| binding_hash     | text         | YES  |     | NULL                |       |
+------------------+--------------+------+-----+---------------------+-------+
9 rows in set (0.001 sec)

But the error still persist. If I drop the column, it gets created again on Vaultwarden restart but it still emits the same error. Some migration logic is cooked.

@jirireischig no it does not.

[jirireischig]

@blind-oracle I was trying all the same things with db update scripts in Vaultwarden with same result.
If you try downgrade your MariaDB libs, your instance will be started OK.

[blind-oracle]

@jirireischig Thanks, this is very weird. At least the symptoms are a bit different.

[CountMurphy]

Had the exact same problem from updating from mariadb 12.2.2 -> 12.3.2 (on Arch). Thanks to @jirireischig I downgraded and everything seems ok. I was a little worried because I ran mariadb-upgrade after the upgrade, but both vaultwarden and mariadb seem fine now.

I think https://github.com/dani-garcia/vaultwarden/blob/d626ea81abf8504b7e54be14b0cfaf45134171b6/migrations/mysql/2026-04-25-120000_sso_auth_binding/up.sql needs a IF NOT EXISTS

[madito]

Hi, it doesn't seem to be related to migrations; it's a problem with the database engine. At least with the latest versions of MariaDB 10.X and 11.X, it doesn't seem to work.

[BlackDex]

I'm not sure what to say here, I'm not able to reproduce this in any way.

I have tried to start with MariaDB v12.2.2 use Vaultwarden v1.35.0, create an account, login etc...
Then updated to MariaDB v12.3.2, start Vaultwarden again, all fine. Then update Vaultwarden to v1.36.0, which does some migrations, and it starts without any issues, no error messages regarding anything.

I tried both Debian and Alpine based images of Vaultwarden and i also tried to go from MariaDB v11 straight to v12, and i can't reproduce the issue in any way.

I think https://github.com/dani-garcia/vaultwarden/blob/d626ea81abf8504b7e54be14b0cfaf45134171b6/migrations/mysql/2026-04-25-120000_sso_auth_binding/up.sql needs a IF NOT EXISTS

That would be illogical, as that column shouldn't exists in the first place, and therefor shouldn't be needed to add that at all.

Maybe something else is wrong in the schema which doesn't pop-up right away? I will dump the final schema of Vaultwarden v1.36.0 here using MariaDB v12.3.2, maybe it helps finding something strange. Note that i just used the defaults regarding charset and collation.

mariadb-schema.sql

[blind-oracle]

@BlackDex

This happens to me stably on Ubuntu 24 with MariaDB 10.11.18 installed from MariaDB's official repos (https://mirror.mva-n.net/mariadb/repo/10.11/ubuntu). It seems to be unrelated to the migration scripts, just some weird client protocol problem probably manifests this way...

Currently I've downgraded to 10.11.16 and pinned it using apt-mark hold - it immediately started to work again.

[madito]

@blind-oracle This also happens in any version of 11.X from Ubuntu onwards. I first tried with 11.4 and then with 11.8 and it's still the same. However, it doesn't happen if we use MySQL or one of the MariaDB versions you mentioned, 10.11.16.

Or it could also be the combination of MariaDB + Ubuntu 24.04.

[BlackDex]

Well, Canonical might have patched their version with some other fixes, or omitted some changes which could be needed maybe? It might even be a different library not even linked to MariaDB it self.

But, the images i used report Ubuntu 24.04 version of the binary, but those are official MariaDB container images, not sure if there is a difference there.

[madito]

Hi!

I found a solution using mariadb from 12.0.2-MariaDB.

The steps

1. Remove old repo and install new:

sudo rm -f /etc/apt/sources.list.d/mariadb.list

sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://mariadb.org/mariadb_release_signing_key.asc | sudo gpg --dearmor -o /etc/apt/keyrings/mariadb.gpg

echo "deb [arch=amd64,arm64 signed-by=/etc/apt/keyrings/mariadb.gpg] https://dlm.mariadb.com/repo/mariadb-server/12.0/repo/ubuntu noble main" | sudo tee /etc/apt/sources.list.d/mariadb.list

2. Set priority MariaDB repo:

sudo tee /etc/apt/preferences.d/mariadb.pref >/dev/null <<'EOF'
Package: *
Pin: origin dlm.mariadb.com
Pin-Priority: 700
EOF

3. Install all
   sudo apt update && apt upgrade

All works fine for me.

Thanks!

[CountMurphy]

That would be illogical, as that column shouldn't exists in the first place, and therefor shouldn't be needed to add that at all.

Probably, but something is causing it to run twice.

Jun 05 08:30:12 harbinger vaultwarden[554083]: [2026-06-05 08:30:12.971][panic][ERROR] thread 'main' panicked at 'Error running migrations: QueryError(DieselMigrationName { name: "2026-04-25-120000_sso_auth_binding", version: MigrationVersion("20260425120000") }, DatabaseError(Unknown, "Duplicate column name 'binding_hash'"))': src/db/mod.rs:501

So started playing with it a little again. I can upgrade the database to 12.3.2, restart the database and vault warden is fine. If I restart vault warden, it throws the above error and crashes. Unfortunately, I'm not running ubuntu so I can't comment on madito's fix. Not sure what else I can do to help. Would running vault warden with strace produce anything useful to help debug? Are there other logs the application writes to that I can share?

[Narrat]

I can upgrade the database to 12.3.2, restart the database and vault warden is fine. If I restart vault warden, it throws the above error and crashes.

That was also the way it happened for me

Maybe something else is wrong in the schema which doesn't pop-up right away? I will dump the final schema of Vaultwarden v1.36.0 here using MariaDB v12.3.2, maybe it helps finding something strange. Note that i just used the defaults regarding charset and collation.

Made a diff against a dump from my db and beside a different locale/collate it has one major difference:

@@ -501,8 +500,9 @@
   `created_at` timestamp NOT NULL DEFAULT current_timestamp(),
   PRIMARY KEY (`user_uuid`),
   UNIQUE KEY `identifier` (`identifier`),
-  CONSTRAINT `sso_users_ibfk_1` FOREIGN KEY (`user_uuid`) REFERENCES `users` (`uuid`) ON DELETE CASCADE ON UPDATE CASCADE
-) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_uca1400_ai_ci;
+  CONSTRAINT `1` FOREIGN KEY (`user_uuid`) REFERENCES `users` (`uuid`),
+  CONSTRAINT `2` FOREIGN KEY (`user_uuid`) REFERENCES `users` (`uuid`) ON DELETE CASCADE ON UPDATE CASCADE
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
 /*!40101 SET character_set_client = @saved_cs_client */;
 

[BlackDex]

Well the only reason Vaultwarden would try to run the migration again is if the migration table doesn't hold the right data, or, if the table is broken in some way.

I'm not sure from the top of my head but maybe setting the log level to this might show the queries executed, also from the migrations.

LOG_LEVEL=debug,vaultwarden::db::query_logger=debug

[blind-oracle]

@BlackDex do you mean the __diesel_schema_migrations table? When the "wrong" MariaDB version is used, it behaves weird - I had the latest migration entry in this table already, but it looked as it wasn't seen by the diesel_migrations somehow and it tried to apply it again. When I removed the last migration, it tried to apply the previous one and so forth.

The tables are for sure not broken (well, at least structurally) - I've dumped the whole DB and restored it alongside the old one fine.

Gonna try with debug.

[BlackDex]

Not sure if I missed something within the Debian ecosystem, but to me it looks like Trixie is still on mariadb 11.8.6, which includes the libs/connector-c around ~3.4.8

The client library reports as v3.4.9. check the example repo i linked

[Narrat]

Not sure if I missed something within the Debian ecosystem, but to me it looks like Trixie is still on mariadb 11.8.6, which includes the libs/connector-c around ~3.4.8

The client library reports as v3.4.9. check the example repo i linked

It was indeed curious. Took a look at the history and found something that may explain it? Back in november 2025, directly after the 3.4.8 release, they already bumped the version number to 3.4.9
mariadb-corporation/mariadb-connector-c@8342a1e

Edit: Although I'm not sure anymore. Does it still fit with the rest?

[BlackDex]

Well it will fit, if Debian cherrypicked several commits except the one that broke the MariaDB<>Diesel combination.

[Narrat]

Looking at the various mariadb releases, they don't follow closely the subsequent connector-c releases or the fixes were deemed necessary.
11.8.6 points to https://github.com/mariadb-corporation/mariadb-connector-c/tree/7bb4e6cdf787b32907429287a636857e3b31e6a1 which is after the version bump, but before the relevant/breaking commit.
If the libs/connector package used from Trixie is built from the mariadb 11.8.6 release, then it would report 3.4.9 I suspect. Not sure if Debian does that, but it would have happened on Arch.

[weiznich]

Ok, I created a repo with a specific branch for this issue so everyone can check and test.

https://github.com/BlackDex/mvp-issues/tree/diesel-mariadb-3.4.9

@weiznich, do you want me to create an issue at the diesel repo?

Thanks, I will try to find some time to look into it hopefully soon. You can create a discussion for this, but as written before, without official support I don't consider it as bug.

[BlackDex]

Thanks, I will try to find some time to look into it hopefully soon. You can create a discussion for this, but as written before, without official support I don't consider it as bug.

Ah sure, discussion is probably the better location indeed.

[weiznich]

Just leaving that as note here as well: This is caused by a breaking change in libmariadb. They stopped providing information they previously documented as being there. See here for a detailed analysis. Feel free to submit an upstream report with that information.

[WanWizard]

I have left a comment with relevant link in the MariaDB Jira ticket (https://jira.mariadb.org/browse/CONC-821)

Thanks very much @weiznich for looking into it! Much appreciated!

[flipreverse]

@BlackDex Do you have any hints on how to start the current HEAD? Currently, I cannot start vaultwarden.

[WanWizard]

@BlackDex Do you have any hints on how to start the current HEAD? Currently, I cannot start vaultwarden.

If you're using MariaDB as a backend, you need to downgrade the client to a version without the issue. Which that is depends on the OS you're using, for RHEL and equivalent you need the 11.8.6 version.

[flipreverse]

For Debian, it is the same version. After downgrading to the stable version, I was able to launch a self-built binary on Debian testing.

[DorianCoding]

Hello,

I have opened also another issue related to libmariadev 11.8.8. Even when forcing the migrations, when connecting I got empty array on the login page instead of the good entry and I therefore cannot connect. SSL/TLS connection cannot be done as well: diesel-rs/diesel#5111 (reply in thread)

It seems to be some compatibility issues with this version.

[vloup]

cc-ing @grawlinson since he's the packager for it and it may interest him somehow if he wants to add a disclaimer of some sort during install.

Opened an issue downstream: https://gitlab.archlinux.org/archlinux/packaging/packages/vaultwarden/-/work_items/13

I think removing support for MariaDB/MySQL is the best outcome for all open source maintainers involved in this.

I know I need to migrate to PostgreSQL, but I have not had some time to take care about the problem yet. Vaultwarden is not the only software running on MariaDB here, and I would like to avoid running two databases in parallel on the same physical host.

Now that 1.37.0-1 in arch has removed MySQL/MariaDB support altogether, I was required to rollback to 1.36.0-1 and add vaultwarden (plus valutwarden-web out of safety) in the NoUpgrade list in /etc/pacman.conf. I would have preferred a message during install that MariaDB was not well supported, while keeping the compile flag in for the users that know what they are doing. After all, it's not a vaultwarden problem, it's libmariadb one, and I was able to use a working lib with LD_LIBRARY_FLAG.
Keeping the old version was something I wanted to avoid (of either full MariaDB or Vaultwarden), but the other option is to fork your PKGBUILD and revert the removal of MariaDB.
I'll upgrade once I have PostgreSQL ready, stable, tested, and with proper backups.

[BlackDex]

I was required to rollback to 1.36.0-1

Know that v1.36 and lower do not work with Bitwarden clients v2026.7.0 and newer,

[BlackDex]

I'm going to close this as this is not something Vaultwarden it self can fix, and not a Vaultwarden coding issue we can solve that quickly.

If users are still having issues with Vaultwarden distributed via other channels then the official Container Images, then i would suggest to report an issue to those packagers and mention https://jira.mariadb.org/browse/CONC-821 which would help them into the right direction.

Our Debian and Alpine based container images both work fine without any issues because those do not have that specific broken version/patch in it.

Ill convert it to a discussion.