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 #35616
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/vaultwarden#35616
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.
@WanWizard commented on GitHub (Jun 17, 2026):
This smells like the typical "it's not us, it's them" response.
For starters, I don't see anyone explaining exactly what the problem is, why the upgrade of the client from 11.8.6 to 11.8.7 breaks Diesel (migrations), but doesn't break anything else. It might be wise to do some research first, before pointing fingers.
In general, as a developer, if your code depends on someone elses code (in this case Vaultwarden ->Diesel -> mysqlclient-sys -> mariadb client libs -> MariaDB C connector), it is your job to ensure compatibility with your dependencies. I agree Vaultwarden itself isn't part of the equation, it has to rely on the Rust ecosystem doing its job.
The most likely culprit is probably mysqlclient-sys. If I check the source, the MariaDB bindings were last updated over 5 months ago, for MariaDB 10.8, so chances are it's running into compatibility issues.
@BlackDex commented on GitHub (Jun 17, 2026):
@WanWizard, As i explained already, we have seen this before with MariaDB. And the response from Diesel and mysqclient-sys (Which are both mainly maintained by the same maintainers) is, that they do not love MariaDB because of these issues that keeps popping up all the time.
I have helped fixing or identifying previous issues in the past, but the maintainers are not happy with MariaDB, and even mentioned dropping support for that fully if nobody steps-up to try and help maintain that library.
I have enough to do with Vaultwarden it self, so that doesn't really help either.
And as mentioned, i build the Alpine/musl based libraries my self, and i also saw that the latest version of MariaDB breaks using that, but did not had time to look into this any further.
And, as you mentioned, we are just a user of those two crates, and would need to lean on the expertise and knowledge of those maintainers to help.
@WanWizard commented on GitHub (Jun 17, 2026):
I understand it's not your problem to fix, and I'm not asking you to.
I have no knowledge of Rust and its ecosystem, so I can't really be of any assistance here, apart from assisting in debugging if and when needed.
But as said, I do have an issue with the "it's them" easy way out. It might be so, but it is an attitude that doesn't solve anything, and doesn't help the users. MySQL/MariaDB is still by far the most deployed DB engine out there, so not supporting it because of an "can't be bothered" attitude from the developers is an enormous disregard of their user base.
Given the fact that lots of solutions out there use the MariaDB C bindings (no database engine is of any use without working clients), solutions vastly more popular and used than mysqlclient-sys (like php-mysqlnd for example), and they don't have any issue. None of our PHP apps failed when we did an OS update round over the weekend.
I have created https://github.com/sgrif/mysqlclient-sys/issues/80 to alert them of this issue.
@BlackDex commented on GitHub (Jun 17, 2026):
I'm not sure where you get that from. I'm only stating what the current reactions could be from Diesel or mysqlclient crates.
I also stated that i have tested this using my musl base images, and encountered it too, but no time yet to check it further.
Also, if any library breaks something in just a patch release, then i certainly think it's more a them issue btw, that doesn't mean trying to look for a solution is out of the question. Both Diesel and mysqlclient crates didn't updated or changed anything, it's the c library, and therefore the main issue lays on that part. That maybe adjustments can be done down stream is nice.
But your statement kinda says that with the recent rsync bugs, that the applications who use the rsync library should fix the rsync issue is not right from my point of view.
@BlackDex commented on GitHub (Jun 17, 2026):
Also, @WanWizard thanks for creating that issue.
@WanWizard commented on GitHub (Jun 17, 2026):
Which is what I was referring to... 😁
I know that. My point remains that if they want to provide MySQL / MariaDB database access to Rust applications, they will have to make sure they update accordingly. Users of Rust don't and shouldn't care what the root cause is, only that it no longer works.
And if they don't, they should drop that support. And suffer the consequences of a development environment without support for the most used RDBMS engine.
As a reference: I maintain a open source PHP development framework (for 15 years now). If a new PHP release comes out, it is my problem to ensure compatibility. I can't tell my users not to upgrade, and I can't tell the PHP community not to release breaking upgrades. It is my problem to deal with, not someone elses.
@BlackDex commented on GitHub (Jun 17, 2026):
But that that PHP version has a bug, that doesn't mean you should jump through hoops to fix it. Or, if a library PHP depends on like PCRE or cURL, it isn't your job to fix it. Helping tracking it down and mentioning it is ok of course, since you might not be a C developer of course.
Also, to be to the letter it's called mysqlclient not mariadbclient.
And if mariadb pretends to be mysqlclient compatible, then they should also adhere to that i think, but clearly isn't their main objective, which is fine.
@WanWizard commented on GitHub (Jun 17, 2026):
Not if it is a bug, no. Then I would have to wait for an upstream fix. But if the API has changed because something underlying has changed, or a bug has been fixed in the API that my code would (unknowningly) depend on, it would be my responsibilty to address the issue by adapting my code.
But we have not established here that a bug in the C connector is to blame, it is all speculation at this point. If that turned out to be the case, I haven't said anything. But it seems unlikely, given the fact no other application using the same libs has this issue, and the widespread use of said libs.
@BlackDex commented on GitHub (Jun 17, 2026):
Well either way, i only stated the current state/feeling regarding MariaDB at both Diesel and mysqlclient crates.
And, i wasn't able to reproduce it my self until i tested the just released version of MariaDB(v3.4.9) last weekend via my musl build image, and after that no time to check any further.
@WanWizard commented on GitHub (Jun 18, 2026):
As you predicted, the response from the Diesel developer was basically "fuck you".
So I guess no developer should ever select the Rust/Diesel combo if they ever think users would want to run their app with the most popular open source RDMBS engine. Lesson to be learned here.
@BlackDex commented on GitHub (Jun 18, 2026):
Well, i think you are to harsh here, and i also kinda agree with weiznich t.b.h.
I have encountered issues with MariaDB in comparison with Oracle MySQL several times too outside of this project.
And as weiznich also mentions, MariaDB happens to work because MariaDB claims to be compatible. But clearly they are not.
I also understand that if Diesel/Mysqlcrate lean on the Oracle MySQL library, and trying to add support for MariaDB separately that will cause more maintenance work that they will not do that.
The same here btw, lot's of people wanted to use something different than the official PostgreSQL server for some reason.
But then, those databases claim to be PostgreSQL compatible, but... then not fully, and you need to make weird adjustments or exclusions or if..else statements to try and make that work. That is very very prone to errors or missing things when trying to add new features. Supporting 3 different databases already is a task by it self even with an ORM.
Also, you keep comparing Rust with PHP, do not forget that PHP is backed by Zend which is a For Profit company and they probably have the resources, which Diesel, mysqlclient-sys and Vaultwarden all have not.
@WanWizard commented on GitHub (Jun 18, 2026):
Perhaps, but when it is about a common low-level component connecting to the most used open source RDMBS deployed, I can't stop thinking about the famous cartoon where the entire ecosystem balances in a tiny component maintained by some open source dude in a shed 😁 . Combined with Spiderman's "with great power comes great responsibility" statement.
I maintain a development framework myself, which contains an ORM too. I can't for one second think I would ever tell the developers that rely on my framework for their apps (and sometimes their livelyhood) to f'off when they encounter a MariaDB (or MySQL, or PostgreSQL) issue. I may not be able to fix it (because of an upstream bug for example, as this may very well proof to be). but I will put the effort in, time permitting, to help the users that have become to depend on my framework for their apps.
As my mentor a long time ago said: "then, one day, you wake up and your attic antics has users. then you have to make a decision, do you keep it like that, or do you acknowledge that fact and professionalise? Even though you might not be employed to do so?".
p.s. PHP has not been a Zend product for a long time. It has the same status where the source of the product is open source (like Linux itself), and commercial comparies provide a supported version with their modifications (like Perforce, which now owns the Zend brand).
@gudzpoz commented on GitHub (Jun 18, 2026):
Ah, I misunderstood, so it is the client library that introduced the breaking change.
I've reproduced this issue with MySQL 9.7, with mariadb-clients library on Arch Linux. Here are the reproducing steps:
This is an *unofficial* Bitwarden implementationbanner from all the logs below.)Now, I believe the binary bundled by Arch has been stripped of its debug symbols. So, here's another way to reproduce it:
Full Stacktrace
However, I couldn't reproduce this with vaultwarden container:
@BlackDex commented on GitHub (Jun 18, 2026):
@gudzpoz, using mysql as a server? Or using the mysqlclient library from mysql? The main issue is the mariadb client library, not which server.
@WanWizard commented on GitHub (Jun 18, 2026):
How I read it, mariadb client (libs) with MySQL server backend.
Problem is this shows the error (which we already knew), but not what is causing the error. That probably needs debugging at the protocol level, to see why Diesel doesn't get any response back.
Without any Rust knowledge, if I read
correctly, it does a check on returned data size there. Which was a fix made in mariadb Connector/C which is part of the 11.8.7 client libs release (incorrect packet size on prepared statements).
edit: this one:
5fe4d03f26@BlackDex commented on GitHub (Jun 18, 2026):
It doesn't matter of its MariaDB or MySQL server used as a backend. It's only the MariaDB client library as far as i could tell.
Not tried newer MySQL client verions though.
@WanWizard commented on GitHub (Jun 18, 2026):
I know. Which is now proven. 😁
@gudzpoz commented on GitHub (Jun 18, 2026):
Thank you for the incredibly quick response (and for maintaining Vaultwarden)! I definitely misunderstood the issue there. (Yes, it was libmariadbclient + MySQL.) It sounds like switching to docker or explicitly installing mysql-clients might be the best options for us users right now. Thanks again!
@weiznich commented on GitHub (Jun 18, 2026):
Given that some users here act like they are entitled to have a fix as soon as possible and expect me to drop everything and to debug a vague problem they don't even care to provide the necessary information for I would like to clarify a few things.
First of all: Diesel never claimed any compatibility with MariaDB. If it worked for you that's great, but you need to understand that this was never something that is supported by us.
Now you could argue: MariaDB is a widely used database system you need to support it. Well, we look for someone to help with this since 8 years: https://github.com/diesel-rs/diesel/issues/1882, so feel free to contribute. My personal take away is that it can't be that important given that in the last 8 years no one needed it that much that they actually contributed. In fact we even lack of a contributor that cares about the MySQL backend, if that doesn't change in the future chances are high that this backend gets deprecated and removed.
If you now argue: You still need to fix the bug as soon as possible let me just ask: Why is you bug more important than the bugs and problems of other users? I can spend my limited amount of time only on a limited amount of fixes. So why should I spend it on something that only affects a smaller fraction of the diesel user base than on something that affects all users? For reference Diesel currently sees around 2 million monthly downloads, pq-sys (the Postgres client library) around 900k downloads, mysqlclient-sys only 80k, so only around 5% of the diesel users have a chance to be affected by this and only a fraction might be affected. That is therefore just no high priority issue for me that warrants dropping everything.
Now if you want to help resolving this here are a few starting points how you can help:
@WanWizard commented on GitHub (Jun 18, 2026):
Eh... Nobody asked you, anywhere, to drop everything. Nobody said this issue is more or less important than all other issues. Nobody said other priorities were not important.
And all I asked for was to be taken serious, and not basically be told to fuck off as soon as I reported it.
I have no problem with reporting it in MariaDB's Jira, but I have no clue what to report. Someone needs to debug it, and explain why result.rs crashes. They can't fix things if they don't know what to fix. Like I said a few times, I am an end-user, have no clue where to start and what to do, and at my age learning a new programming language just because of a debugging issue is a bit too much to ask.
@stefan0xC commented on GitHub (Jun 19, 2026):
@WanWizard your characterization of @weiznich response is unfair because it was neither "fuck you" nor "fuck off" but a plea to provide more infos (e.g. a minimal reproducible example) https://github.com/sgrif/mysqlclient-sys/issues/80#issuecomment-4734532289 to which you responded basically that you can't be bothered with that. The insistence that MariaDB is not an officially supported backend by diesel is not a fuck off either but an important clarification why you can't expect a fix any time soon. If you want to be taken seriously you should act more respectfully and empathetic and not list reasons why people should work on this issue with bogus claims (e.g. that MariaDB is more popular than either MySQL or Postgres).
Yes and the same is true for @weiznich but instead of accepting that you argued that the response you got was somehow wrong and that you are disappointed. Venting your frustrations on maintainers like you did in https://github.com/sgrif/mysqlclient-sys/issues/80#issuecomment-4741699874 or in this thread is not helping anyone but leads only to the problem of maintainer burnout. So please stop doing that.
@xalt7x commented on GitHub (Jun 19, 2026):
@madito
I've tested with Debian 12 and 13 with the packages from https://github.com/dionysius/vaultwarden-deb
If I install MariaDB from the Debian, Vaultwarden+MariaDB works fine
Debian 12 currently provides version 1:10.11.16+maria~deb12 ; Debian 13 — 1:11.8.6-0+deb13u1
If I use MariaDB repo and upgrade to the latest minor version of the 10.x, Vaultwarden doesn't start with the error like
That happens after the clean install, user creation and service restart.
Also, the initial user creation doesn't work properly. After the user creation, normally Vaultwarden shows the page that asks to either install extension or "Skip to web app". With incompatible MariaDB, it redirects to the login page where the password doesn't work.
Downgrading packages to either Debian repo version, or older minor MariaDB version fixes the issue.
For 10.11, the latest working version is really 10.11.16. However, I'd rather recommend using Debian version to receive security updates.
@vloup commented on GitHub (Jun 20, 2026):
Okay, I think I built a stupid workaround for arch linux users that do not particularly want to downgrade MariaDB to 12.2.2 (from 12.3.2) by keeping the old client lib around for vaultwarden. Not an ideal solution, but it was fun to build and seem to work. That might interest you @marcusweinhold.
First download the old package mariadb-libs 12.2.2-2 from https://archive.archlinux.org/packages/m/mariadb-libs/mariadb-libs-12.2.2-2-x86_64.pkg.tar.zst. Unpack it with zstd and tar and only keep
libmariadb.so.3. Store it inside/var/lib/vaultwarden.Then in your config in
/etc/vaultwarden.env, just add the lineLD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/var/lib/vaultwardenand you're golden.(If you quote this anywhere else, please refer to this discussion)
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.
While I see others issues were created for diesel-rs and mysqlclient-sys. I have to agree for the few lines of code I read that vaultwarden is not doing anything fancy (disclaimer I don't know rust). Has anyone reached the MariaDB folks? Has there been other similar breakages in other programming ecosystems with this update?
@grawlinson commented on GitHub (Jun 20, 2026):
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.
@osc86 commented on GitHub (Jun 20, 2026):
I ran into the same issue after updating my OpenBSD system today (mariadb-client-11.4.12v1). From what I've read, the maintainer is unwilling to provide support for MariaDB, which is fine. What is our best option now, switch to postgres? I can't simply downgrade packages on OpenBSD; that won't work long term.
Edit:
I decided to downgrade anyway, although I know I'll be shooting myself in the foot. I currently have no other option.
@WanWizard commented on GitHub (Jun 21, 2026):
That leaves those of us that have no choice in the cold.
Besides that, as I understand the problem is only MariaDB, not MySQL, so removing MySQL support to might be a bit harsh.
@grawlinson commented on GitHub (Jun 21, 2026):
You’ve got the option of switching to a better DB provider, and in regards to open source, support is not guaranteed at all. The maintainer for diesel has explicitly referenced a standing bug (for 8 years!) that anyone can hop in and fix. That it hasn’t happened yet really does prove that you shouldn’t even be depending on MariaDB.
We don’t package MySQL on Arch, so that’s a moot point for us.
@BlackDex commented on GitHub (Jun 21, 2026):
And other distro's the same.
Besides that, Oracle MySQL doesn't build on 32bit anymore, they do not support that, and that kinda is an issue for us too.
@WanWizard commented on GitHub (Jun 21, 2026):
If you're a home user, yes, perhaps. Or use any other solution available, like a self-contained docker image for example.
But in my case, it runs in a strict secure managed hosting environment were I have none of the options, everything runs (and must run) on RHEL servers using a shared MariaDB Galera cluster. And I have to work with that.
For both, YMMV. I have to work with RHEL (which is 64-bit), which has both the MariaDB and MySQL client libs available. And as long as the hosting provider doesn't migrate to EL10 or an incompatible version of MariaDB,, I'm perfectly happy with pin the client libs for this server to v11.8.6, as it is dedicated for VaultWarden.
Technically I could ask them to install PostgreSQL locally, but they won't support it, so no monitoring, 24/7 management, backups and offsite backups,. etc.
@weiznich commented on GitHub (Jun 21, 2026):
Maybe you shouldn't rely on random persons on the internet for fixing issues for you then? It's always an option to contract someone to do the necessary work for you or even fund the work directly.
@WanWizard commented on GitHub (Jun 21, 2026):
Maybe not, after all, that is why you immediately responded with the usual "no warranties, fuck off" waiver.
However, I and many others here are not developers, but end-users of Vaultwarden. It is not our business, or our problem, that things are broken in Vaultwarden because of upstream issues in their development stack.
Appearently the Vaultwarden developers have collided with your attitude before up to the point they no longer want (or dare?) to report issues upstream, which is the only reason I did it.
It is up to the Vaultwarden developers to respond to this issue, and if they are forced to stop supporting their app on MariaDB (because of the issue) and MySQL (which works fine but uses the same crate), and up to us end-users to respond to that.
As to the issue at hand, I've offered several times to report it to MariaDB (I have a Jira account there), but as I don't know Rust, and have no clue how to debug it and tell them exactly what is wrong, I can't. And appearently you are unwilling to even help with that. And you know as well as I do, bug reports limited to "it doesn't work" are closed immediately.
@weiznich commented on GitHub (Jun 21, 2026):
@WanWizard I just want to clarify something for others here:
I can assure you that this is not the case, the last such discussion happened on Friday. You can check that yourself by going in the mysqlclient-sys issue tracker.
MariaDB was never supported from Diesels point of view. Therefore we cannot stop support for it, it never existed in the beginning.
As for MySQL: The only party I see that is talking about ending support for MySQL are the ArchLinux package maintainers, as for them MySQL means MariaDB. Given these assumptions that's a reasonable decision in my opinion.
The other thing I want to call out again: At no point I wrote a "fuck you" or similar response. It's just without a minimal reproducible example it's much harder to even understand what's the issue at all. Usually the burden to build such a example is on the reporter and not the maintainer, but you couldn't even be bothered to provide even basic information about your environment or what is broken. At that point it's just wasting time for any maintainer to interact with you. Even with that, I might, as expressed, at some point look into this. It's just not a priority for me. Now to be clear: Due to your toxic attitude and the missing reproduction information it is moving down on my priority list.
Finally: You always claim you cannot help with the reproduction information, as you are no rust developer. That's not true, as basic information can be provided by anyone. Beside of that, even a minimal example ca be build by someone motivated without rust knowledge, you just need to remove code from the original application until the code is small. Yes it's a bit harder without knowledge of the language, but certainly possible. If even that is too hard for you, you certainly can hire a Rust developer to do it for you.
It unclear why you expect me to track down the issue, but the MariaDB developers need a minimal reproducible example for that.
@WanWizard commented on GitHub (Jun 21, 2026):
I don't expect that, I am willing to put the effort in myself. But I have never seen one line of Rust in my life, and the last C I wrote was 35 years ago. So I need help in the debugging process, and that doesn't have to be from you.
@BlackDex commented on GitHub (Jun 21, 2026):
Let me make one thing very clear, I have never collided with any
diesel,mysqlclient-sys,pq-sysorlibsqlite3-sysdeveloper ever. I only mentioned their view on MariaDB, which is fine from my point of view. It's not up to me to decide what they should support or not. We thankfully use Diesel's ORM, and @weiznich even added features to Diesel which Vaultwarden was a sole user of. I have helped fixing issues withdiesel,mysqclient-sysin the past and I will try to do so if i have the time.As a side-note, I was also working on trying to get a MVP for this issue to try and find it my self, but i also have other stuff to do, and not yet had the time to work on this.
I would also like this whole debate to stop and from now on only focus on the specific issue.
So, either posts which point to a MVP which can help @weiznich (and us) solve this issue, or specific combinations which work and not work, like Oracle-MySQL client version x.y.z. also does not work for example, or it started since MariaDB version x.y.z etc... , else please refrain from posting anything.
And, a personal note, this whole nasty vibe in the comments here also do not make me want to put any more haste into trying and fixing this, even though I probably know this will break Debian container images with updated packages.
Also, in the order of transparency, I'm going to hide the Off-Topic posts to keep this issue a bit more on-topic.
Thanks for your patience!
@Narrat commented on GitHub (Jun 21, 2026):
There is regression report for the Connector/C project, which explicitly mentions
libmariadband the involved version jumps:https://jira.mariadb.org/browse/CONC-821
Could it be possibly apply for this situation? Especially as the report mentions broken/wrong return values.
I will attempt builds of 12.3.2 with the mentioned commits one after another being reverted and see what happens.
@BlackDex commented on GitHub (Jun 22, 2026):
Ok, I build an Alpine version of Vaultwarden using v3.4.9, and that fails.
I tried building it with the
CONC-812patch reverted, that also failed, so it probably isn't something linked to that specific issue or the fix.I then tried to build with v3.3.19, that fails, v3.3.18 that works just fine, so some change for both versions is causing this specific issue, but probably not
CONC-812.Checking further when i have more time.
@Narrat commented on GitHub (Jun 22, 2026):
Got around to testing my builds. Not the commit in regards to CONC-812 is the problem, the follow-up commit is?
With just the latter reverted vaultwarden started successfully.
Could someone confirm?
@WanWizard commented on GitHub (Jun 22, 2026):
I saw that commit too, but dismissed as it looked cosmetic. But I now see that hidden in all the cosmetic stuff in the diff is the length update.
Thanks very much for spending your time debugging this! Let me know if you want me to open a Jira ticket to have it looked at?
@Narrat commented on GitHub (Jun 22, 2026):
Was in the middle of making a meal, when I saw your message and let me tell you, my heart dropped :D Didn't expect success after that.
As my post was rather short I will follow up on this with my findings in regards to
mariadb-connector-c 3.3and3.4branch.CONC-812is part of both.Which commit points the submodule libmariadb to
MariaDB 10.11.x ( https://mariadb.com/docs/release-notes/community-server/10.11 )
7a5c80e85e93bb92666693bb926666MariaDB 12.2.x
7bb4e6cdf7MariaDB 12.3.x
7bb4e6cdf764e9fe09felibmariadb/Connector differences between releases:
3.3.18 -> 3.3.19
https://github.com/mariadb-corporation/mariadb-connector-c/compare/v3.3.18...v3.3.19
3.4.8 -> 3.4.9
https://github.com/mariadb-corporation/mariadb-connector-c/compare/v3.4.8...v3.4.9
The mariadb releases involved construct a timeframe between February 2026 and May 2026.
Whereas the former connector releases were from December 2025.
Therefore only check from the pinned commits forward
Commits in
mariadb-connector-cinbetween10.11.16and10.11.18(connector 3.3.18+) which appear in theconnector-c branch 3.4fix for https://jira.mariadb.org/browse/CONC-812
follow-up on 5fe4d03f26045
Fix MARIADB_TIMESTAMP calculation and packing (CONC-815)
MDEV-38550 add LENENC support for COM_CHANGE_USER
CONC-819 mysql_real_escape_string incorrectly handles big5
Fix memory leaks if binlog is disabled
[misc] add maxscale testing
[misc] Skip test_conc26 on MaxScale
@Narrat commented on GitHub (Jun 22, 2026):
That would be great, as I don't have a Jira account. But I would wait for confirmation from a second person.
Not sure if a new ticket would be necessary though, as https://jira.mariadb.org/browse/CONC-821 is about the follow-up commit if I understand the description correctly. Therefore it would suffice to comment on that ticket?
(and yeah.. the cosmetic whitespace fixes weren't helping, but luckily the effective diffs were small)
@BlackDex commented on GitHub (Jun 22, 2026):
I can verify this building the Alpine based container via my rust-musl docker images.
Only reverting that specific commit, and only the mariadb_stmt.c resolved the issue for me too.
So, we at least have narrowed down to which commit broke the migrations. That will help a lot.
@BlackDex commented on GitHub (Jun 23, 2026):
After a bit more checking yesterday it looks like the
min()andmax()dslfeatures seem to break.I almost got a working example ready.
@BlackDex commented on GitHub (Jun 23, 2026):
What also is strange, Debian Trixie seems to use v3.4.9, but the issue is not happening there, maybe their version didn't patched everything, or they patched it them self.
Ill keep checking further.
@BlackDex commented on GitHub (Jun 24, 2026):
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
dieselrepo?@Narrat commented on GitHub (Jun 24, 2026):
Not sure if I missed something within the Debian ecosystem, but to me it looks like
Trixieis still onmariadb 11.8.6, which includes thelibs/connector-caround~3.4.8? At least when I look here and here (on the right side where they show the badges)? ButSidshould have11.8.8with3.4.9.And they did no patching in that regard, as the head of their repo contains the changes in question.
That aside: Thank you very much for all the work in researching and creating this reproducer :)
@BlackDex commented on GitHub (Jun 24, 2026):
The client library reports as v3.4.9. check the example repo i linked
@Narrat commented on GitHub (Jun 24, 2026):
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
8342a1e1c4Edit: Although I'm not sure anymore. Does it still fit with the rest?
@BlackDex commented on GitHub (Jun 24, 2026):
Well it will fit, if Debian cherrypicked several commits except the one that broke the MariaDB<>Diesel combination.
@Narrat commented on GitHub (Jun 24, 2026):
Looking at the various
mariadbreleases, they don't follow closely the subsequent connector-c releases or the fixes were deemed necessary.11.8.6points to7bb4e6cdf7which 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.6release, then it would report3.4.9I suspect. Not sure if Debian does that, but it would have happened on Arch.@weiznich commented on GitHub (Jun 24, 2026):
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 commented on GitHub (Jun 24, 2026):
Ah sure, discussion is probably the better location indeed.
@weiznich commented on GitHub (Jun 26, 2026):
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 commented on GitHub (Jun 26, 2026):
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 commented on GitHub (Jul 8, 2026):
@BlackDex Do you have any hints on how to start the current HEAD? Currently, I cannot start vaultwarden.
@WanWizard commented on GitHub (Jul 8, 2026):
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 commented on GitHub (Jul 8, 2026):
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.