mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-07-17 01:12:27 -05:00
[GH-ISSUE #7268] Error MariaDB 11.X #30156
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/vaultwarden#30156
Reference in New Issue
Block a user
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?
Originally created by @madito on GitHub (May 28, 2026).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/7268
Prerequisites
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 commented on GitHub (May 29, 2026):
This problem look like similar to #7241
@blind-oracle commented on GitHub (Jun 1, 2026):
The same happens for me. The
binding_hashcolumn from migration script (d626ea81ab/migrations/mysql/2026-04-25-120000_sso_auth_binding/up.sql) gets created: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 commented on GitHub (Jun 1, 2026):
@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 commented on GitHub (Jun 1, 2026):
@jirireischig Thanks, this is very weird. At least the symptoms are a bit different.
@CountMurphy commented on GitHub (Jun 3, 2026):
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.sqlneeds aIF NOT EXISTS@madito commented on GitHub (Jun 4, 2026):
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 commented on GitHub (Jun 5, 2026):
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.
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 commented on GitHub (Jun 5, 2026):
@BlackDex
This happens to me stably on Ubuntu 24 with MariaDB
10.11.18installed 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.16and pinned it usingapt-mark hold- it immediately started to work again.@madito commented on GitHub (Jun 5, 2026):
@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 commented on GitHub (Jun 5, 2026):
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 commented on GitHub (Jun 5, 2026):
Hi!
I found a solution using mariadb from 12.0.2-MariaDB.
The steps
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
sudo tee /etc/apt/preferences.d/mariadb.pref >/dev/null <<'EOF'
Package: *
Pin: origin dlm.mariadb.com
Pin-Priority: 700
EOF
sudo apt update && apt upgrade
All works fine for me.
Thanks!
@CountMurphy commented on GitHub (Jun 5, 2026):
Probably, but something is causing it to run twice.
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
straceproduce anything useful to help debug? Are there other logs the application writes to that I can share?@Narrat commented on GitHub (Jun 6, 2026):
That was also the way it happened for me
Made a diff against a dump from my db and beside a different locale/collate it has one major difference:
@BlackDex commented on GitHub (Jun 7, 2026):
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 commented on GitHub (Jun 7, 2026):
@BlackDex do you mean the
__diesel_schema_migrationstable? 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 thediesel_migrationssomehow 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.
@sarah4d2 commented on GitHub (Jun 7, 2026):
We are seeing the same issue as @blind-oracle described with Vaultwarden 1.35.2 on FreeBSD 14.4, after upgrading from MariaDB 11.4 to MariaDB 11.8.8 from ports.
As an example, migration
20250109172300has already been completed:But Vaultwarden tries to run this migration again on start:
The above is after manually dropping the
managecolumn fromuser_collectionsandcollections_groupsin an attempt to get the migration to succeed; otherwise it would have failed on the ALTER TABLE statements instead of the INSERT.I've tried a few rounds of manually reverting the changes made by migrations and removing their corresponding rows from
__diesel_schema_migrations- as @blind-oracle said, Vaultwarden just tries to apply the previous migration. It's as though the relevant row isn't seen in the result from the select against__diesel_schema_migrations, though as shown above, running the exact query in the mariadb client returns the expected results.@sarah4d2 commented on GitHub (Jun 7, 2026):
This is somewhat desperate and may not be helpful, but I attempted to do the following:
This resulted in another crash that might indicate a broader problem interacting with the DB:
Trying the same query via mariadb client yields the expected result:
@BlackDex commented on GitHub (Jun 7, 2026):
@sarah4d2, which container image are you using? Debian or Alpine based? What if you use the other, my guess is you are using the Debian based, and i wonder what the Alpine based image does, since that uses a different client library.
@sarah4d2 commented on GitHub (Jun 7, 2026):
@BlackDex, this is a build from source automated with FreeBSD Ports. The source tarball it's using is identical to https://github.com/dani-garcia/vaultwarden/archive/refs/tags/1.36.0.tar.gz. The build machine is using rustc 1.95.0.
I would normally assume an issue with the port or dependencies vs. commenting on an upstream issue like this, but it seems very similar to the reports here. We ran into this trying to upgrade from Vaultwarden 1.35.2 to 1.36, after upgrading from MariaDB 11.4 to 11.8 with vaultwarden running. Rolling back to a backup copy of the 1.35.2 vaultwarden binary that was running before the upgrade from MariaDB 11.4 to 11.8, and restoring the old DB, doesn't fix the problem (or maybe introduces a different problem, since this binary was built against MariaDB 11.4).
@Narrat commented on GitHub (Jun 7, 2026):
The smallest version jump mentioned with mariadb was an update from
10.11.16to10.11.18. Had a hope looking at the changelogs in question would maybe point to a culprit. But10.11.17is a big one...Running with the mentioned
LOG_LEVELyields a similar result like reported by sarah4d2. Difference being I didn't drop any migrations and according to the log it didn't try to create a new entry in that table. But still wants to apply the most recent migration:Therefore in my case it went with
2026-04-25-120000_sso_auth_binding, which according to the entry in__diesel_schema_migrationswas already run:And fits to the error. (But doesn't explain why I have the difference in structure.)
Is there an additional logger option which could enlighten what happens with the results from the QUERY as this returns a list of all run migrations?
@marcusweinhold commented on GitHub (Jun 9, 2026):
I have a similar issue on Archlinux:
@vloup commented on GitHub (Jun 13, 2026):
@Narrat has a good summary of the situation. I also proof checked, all the collations and charsets are correct.
Here's the general_log output on my side, this matches what had been seen with the vaultwarden logs:
With the SELECT query returning:
Yet it wants to replay the migration.
Funnily enough, I see there's a new migration in
main. If I play it manually, I can boot the app, but like @marcusweinhold said, with 12.3.2 all master password cannot be verified. It might only be the top of the iceberg.I tried fresh-rebuilding the app, as a way to ensure the linker used the right libraries, to no effect.
@sarah4d2 commented on GitHub (Jun 14, 2026):
I wonder whether this is a Diesel issue? It seems like it can be generalized as "all select queries return empty result sets on recent versions of MariaDB".
@BlackDex commented on GitHub (Jun 14, 2026):
And what about using the Alpine binary? How does that work with all these versions?
@BlackDex commented on GitHub (Jun 14, 2026):
Those could be downloaded via here if needed.
https://github.com/dani-garcia/vaultwarden/actions/runs/27036784937
@WanWizard commented on GitHub (Jun 17, 2026):
We run Vaulwarden on Redhat EL9, against a shared MariaDB 11.8.6 cluster..
Just did a
dnf updateof the server, with the same outcome as everyone else here: vaultwarden doesn't start since it wants to run migrations that have already run.The update installed MariaDB client 11.8.8. I've downgraded the MariaDB client packages back to 11.8.6, and that fixed the issue.
@BlackDex commented on GitHub (Jun 17, 2026):
I suspect you then also use a DNF/RPM Package to install Vaultwarden?
In that case, I'm afraid there isn't something we can do on our end. It's either a Diesel issues, or a MariaDB issue.
And I already know the response from Diesel, they will blame MariaDB (And probably rightfully so) to be changing stuff or not upholding standards defined in the API them self.
MariaDB has had several issues in the past regarding compatibility or RFC's.
@BlackDex commented on GitHub (Jun 17, 2026):
Well, the only thing we can do is add a special feature,
mysql_bundledwhich then forces the static building of the Oracle MySQL client library, but that might also bring other issues. And, it also doesn't work for all architectures, and currently needs dependencies to build (which in the end are not even used though).@WanWizard commented on GitHub (Jun 17, 2026):
@BlackDex yes, but that is not the issue.
The migrations fail when using MariaDB client 11.8.7 or newer, but work with 11.8.6.
Irrespectively of how Vaultwarden was installed, and probably also which version.
I don't know what has changed in the MariaDB client from 11.8.6 to 11.8.7 that causes Diesel to trip, I've got tons of apps here that are MariaDB backed (we run a hosting company), and none of them have this issue, so it is clearly the way Diesel and MariaDB interact.
@BlackDex commented on GitHub (Jun 17, 2026):
I understand that, this is because libmariadb is a dynamic library. It has nothing to do with how Vaultwarden was build.
Also, from my opinion (and probably also that of Diesel), MariaDB created a breaking change in a patch level version.
Maybe if you report this issue at the Packager of the Vaultwarden package, they can report this somewhere at RHEL or Fedora or where ever and maybe they can figure it out.
The same goes for Debian btw. I can report this again at Diesel or at the mysqlclient crate, but that would probably result in me having to figure it out and troubleshoot it my self since they only support MariaDB as-is or best-effort.
My problem with that is, that a lot of distro's stopped providing Oracle MySQL client packages because of licensing issues if I'm correct. Though, Oracle has changed this, but not all distro's started providing these packages again.
And, also, sometimes installing both versions isn't possible, or might even break other applications mainly depending on MariaDB instead of MySQL.
If someone has more insights regarding this, or knows a briljant way to solve this for all Distro's and architectures we currently build, that would be great! Since the mysqlclient crate doesn't build on armv7 for example.
armv6/armv5 will be another issue in the future, as Debian stops providing packages and releases for that with the coming new release.
For our Alpine based images there is no issue, as I decide which version of MariaDB will be used. Which i tested, but also breaks using the latest version of MariaDB.