mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-03-16 11:50:18 -05:00
2FA Login Error on 1.23.1 #1171
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 @emaraszek on GitHub (Dec 18, 2021).
Subject of the issue
Cannot login as a user with 2FA enabled after updating from 1.23.0 to 1.23.1
Deployment environment
Install method: Docker
Clients used: web vault, desktop, iOS
Reverse proxy and version: Traefik 2.5.5
MySQL/MariaDB or PostgreSQL version: MariaDB 10.6.5
Other relevant details:
Steps to reproduce
Expected behaviour
User is prompted to enter TOTP code and is logged in successfully after doing so.
Actual behaviour
Login page displays an error message ("Error adding twofactor_incomplete record") and the container log displays the following:
Troubleshooting data
Log file: _Bitwarden_logs.txt
@ndonkersloot commented on GitHub (Dec 20, 2021):
It works for me, i also run vaultwarden in docker.
Are you sure you have the correct time set on the docker host?
You can check this on the admin page in the diagnostics tab. Is "Date & Time (UTC)" marked with "OK"?
@emaraszek commented on GitHub (Dec 21, 2021):
yeah that's marked as "Ok" for me as well

@BlackDex commented on GitHub (Dec 21, 2021):
I think you need to change your database charset/collation. Please see https://github.com/dani-garcia/vaultwarden/discussions/1492#discussioncomment-544064
@emaraszek commented on GitHub (Dec 21, 2021):
Ok, I just ran through those steps. All tables were converted correctly, except 'invitations'. That produced an error message:
#1071 - Specified key was too long; max key length is 1000 bytesI just recreated the container with 1.23.1 and am still having the same issue when attempting to login. Reverting back to 1.23.0 again for now.
@jjlin commented on GitHub (Dec 21, 2021):
twofactor_incompleteis a new table, which you presumably also need to convert.@BlackDex Maybe you can update your comment, or perhaps just add it to the wiki.
@BlackDex commented on GitHub (Dec 21, 2021):
Well, those commands are generated actually by the querie above.
So it should only add the tables which are there, it could be that @emaraszek didn't run the
SELECT CONTACT...query and just copied the example?But it stated that the key was too long. I think this is because some conversion from what it was, i think latin1 or something, to utf8mb, which is longer indeed.
@emaraszek could you run the following query and show us the output?
It should output something like this:
@BlackDex commented on GitHub (Dec 21, 2021):
btw @jjlin i updated the wiki: https://github.com/dani-garcia/vaultwarden/wiki/Using-the-MariaDB-(MySQL)-Backend#foreign-key-errors-collation-and-charset
@emaraszek commented on GitHub (Dec 23, 2021):
@BlackDex I did run the
SELECT CONTACT...query as instructed, which did pick up the twofactor_incomplete table. That table appears to have converted correctly:However, the invitations table has not been converted and returns the following:
I do have 2 unaccepted invitations pending, so perhaps that could be the cause? However, that seems like a separate issue from the MFA login problem on 1.23.1
@BlackDex commented on GitHub (Dec 23, 2021):
What i find strange is that one table is using innodb and the other myisam. Did you changed database backends or updated the configuration? All should be the same. And they all should be utf8mb.
@emaraszek commented on GitHub (Dec 23, 2021):
@BlackDex Thank you, your last comment highlighted an issue with my environment that I had missed.
I did migrate from SQLite to MariaDB a couple years ago, so these tables must have been using MyISAM since then. I could see that newer tables (twofactor_incomplete, sends, emergency_access) were using InnoDB as expected. I did follow the migration guide in the wiki, so I'm not sure if I missed something or my migrated tables defaulted to MyISAM for some reason.
I did a mass-conversion of all tables to InnoDB using a similar approach to your query:
After changing all tables to InnoDB, I was able to set the charset/collation properly using your query. I then recreated the container with 1.23.1 and was able to login successfully.
Perhaps this should be added to the wiki as well?