mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-02-05 00:29:40 +03:00
Unable to login after upgrade to 1.9 (no such column: users.key) #360
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 @djakielski on GitHub (Aug 5, 2019).
Hey guys,
after upgrade to the latest version 1.9.1, i can't login anymore. It's told me that my credentials are wrong, but they aren't
[2019-08-05 08:20:18][rocket::rocket][INFO] POST /api/accounts/prelogin application/json; charset=utf-8:
[2019-08-05 08:20:18][][INFO] Matched: POST /api/accounts/prelogin (prelogin)
[2019-08-05 08:20:18][][INFO] Outcome: Success
[2019-08-05 08:20:18][][INFO] Response succeeded.
[2019-08-05 08:20:18][rocket::rocket][INFO] POST /identity/connect/token application/x-www-form-urlencoded; charset=utf-8:
[2019-08-05 08:20:18][][INFO] Matched: POST /identity/connect/token (login)
[2019-08-05 08:20:18][bitwarden_rs::error][ERROR] Username or password is incorrect. Try again. IP: 10.42.0.0. Username: xxxxxxxxxxx.
[2019-08-05 08:20:18][][INFO] Outcome: Success
[2019-08-05 08:20:18][][INFO] Response succeeded.
If i try to login on admin page, i got on error message in log.
[2019-08-05 08:19:48][][INFO] Matched: GET /admin (admin_page)
thread '' panicked at 'Error loading users: DatabaseError(__Unknown, "no such column: users.key")', src/libcore/result.rs:999:5
note: Some details are omitted, run with
RUST_BACKTRACE=fullfor a verbose backtrace.stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
1: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:71
2: std::panicking::default_hook::{{closure}}
at src/libstd/sys_common/backtrace.rs:59
at src/libstd/panicking.rs:197
3: std::panicking::default_hook
at src/libstd/panicking.rs:211
4: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:474
5: std::panicking::continue_panic_fmt
at src/libstd/panicking.rs:381
6: rust_begin_unwind
at src/libstd/panicking.rs:308
7: core::panicking::panic_fmt
at src/libcore/panicking.rs:85
8: core::result::unwrap_failed
9: bitwarden_rs::api::admin::rocket_route_fn_admin_page
10: ::handle
11: rocket::rocket::Rocket::route_and_process
12: <rocket::rocket::Rocket as hyper::server::Handler>::handle
13: hyper::server::Worker::handle_connection
14: hyper::server::listener::spawn_with::{{closure}}
[2019-08-05 08:19:48][rocket::rocket][INFO] GET /favicon.ico image/webp:
[2019-08-05 08:19:48][][INFO] Matched: GET /<p..> [10] (web_files)
[2019-08-05 08:19:48][][INFO] Outcome: Success
[2019-08-05 08:19:48][][INFO] Response succeeded.
[2019-08-05 08:20:05][rocket::rocket][INFO] GET / text/html:
[2019-08-05 08:20:05][][INFO] Matched: GET / (web_index)
[2019-08-05 08:20:05][][INFO] Outcome: Success
[2019-08-05 08:20:05][][INFO] Response succeeded.
I use the sqlite db with structure of users table:
CREATE TABLE users (
uuid TEXT NOT NULL PRIMARY KEY,
created_at DATETIME NOT NULL,
updated_at DATETIME NOT NULL,
email TEXT NOT NULL UNIQUE,
name TEXT NOT NULL,
password_hash BLOB NOT NULL,
salt BLOB NOT NULL,
password_iterations INTEGER NOT NULL,
password_hint TEXT,
akey TEXT NOT NULL,
private_key TEXT,
public_key TEXT,
totp_secret TEXT,
totp_recover TEXT,
security_stamp TEXT NOT NULL,
equivalent_domains TEXT NOT NULL,
excluded_globals TEXT NOT NULL
, client_kdf_type INTEGER NOT NULL DEFAULT 0, client_kdf_iter INTEGER NOT NULL DEFAULT 5000);
Could you help me to get the right version of my database that matches to v1.9.1.
@mprasil commented on GitHub (Aug 6, 2019):
This sounds like you're trying to run 1.9.1 with DB updated to the latest version. Can you try to update to latest?
@kabaga commented on GitHub (Aug 10, 2019):
I rarely use the web UI, but I just realized today, I was getting the same error. The docker container repo that I am using is mprasil/bitwarden. This is on Unraid server.
EDIT:
This is the error that I am getting:
Error sending email. 5.7.8 Username and Password not accepted. Learn more at@mprasil commented on GitHub (Aug 10, 2019):
@kabaga you should stop using
mprasil/bitwardenand start usingbitwardenrs/server- this is the current official image.@kabaga commented on GitHub (Aug 11, 2019):
@mprasil I changed the repo to the
bitwardenrs/server, but I still could not login with the same error.@mprasil commented on GitHub (Aug 11, 2019):
Not sure if I understand you correctly. You can use the service with other clients but can't log in with vault?
@kabaga commented on GitHub (Aug 11, 2019):
@mprasil Yes, the mobile app and browser extension work, but can't log in to the web vault using any browser.
EDIT:
I got it working now. It is weird and not sure why it worked before until a few days ago. I have the smtp enabled and using gmail. I enabled 2FA and generated an app password for bitwardenrs. After updating the container settings, everything works again.
Are you discontinuing the
mprasil/bitwarden?@mprasil commented on GitHub (Aug 12, 2019):
Glad you got it working. Yes,
mprasil/bitwardenwill be discontinued, I still compile the latest version every now and then, but the idea is to move all users to the official image now that we have it.@mprasil commented on GitHub (Aug 12, 2019):
@djakielskiadesso any update on your side? Did you try the latest version?
@djakielski commented on GitHub (Aug 12, 2019):
@mprasil Thanks for your notes.
I used an backup where the DB wasn't upgraded and than starting version 1.9.1 again. I also switched to the bitwardenrs/server:1.9.1 Image and it works fine.
I dont like to use the latest tag. My problem with this is, that you can't easily roll back from current latest to privious latest version. On k8s you have to configure ImagePullPolicy to allways, which make it much slower to start. This error midght be the result from using latest and switch to an stable version number. Correct me if i am worg, but the highest version i found was 1.9.1 and it's two month old. My expectation is, that this is the latest stable release. So it would be very nice, if you could tag each release with an uniqe tag.
@mprasil commented on GitHub (Aug 13, 2019):
Yeah, generally speaking there is new version release when there's some major change or some change that requires DB schema change (these would be backwards incompatible changes usually, unless you want to mess with the schema) or when there's enough changes to justify new version.
Historically the pace of development was very fast to catch up with upstream server API, so the versions were released about once a month, sometimes faster. Now that there's a bit less changes required to keep up with upstream, you'll probably see less frequent releases.
As for why this happened, I'd agree with you, that you had to run the
latestat some stage which updated the DB version.@mprasil commented on GitHub (Aug 13, 2019):
I'm closing this as it seems to be resolved.