no password when update to 1.11.0
-
@luckow thanks for digging this out - I just realized I have vaultwarden broken since the latest update, which is happened at 24th of Dec for me.
Here is the short instructions and extract based on @luckow findings:
On Web GUI:
- go the app
- click terminal
Now on the terminal:
echo ${CLOUDRON_MYSQL_DATABASE} # note the output - it's 35629ca3ac8992ec in my case mysql --user=${CLOUDRON_MYSQL_USERNAME} --password=${CLOUDRON_MYSQL_PASSWORD} --host=${CLOUDRON_MYSQL_HOST} ${CLOUDRON_MYSQL_DATABASE}
Now starts making database voddoo - make sure you have database backup first.
SELECT * FROM information_schema.SCHEMATA WHERE schema_name = "35629ca3ac8992ec"; SELECT CONCAT('ALTER TABLE `', TABLE_NAME,'` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;') AS CharSetConvert FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA="35629ca3ac8992ec" AND TABLE_TYPE="BASE TABLE"; ALTER DATABASE `35629ca3ac8992ec` CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; SET foreign_key_checks = 0; /* execute all queries from CharSetConvert output earlier here */ ALTER TABLE `__diesel_schema_migrations` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `attachments` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `ciphers` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `ciphers_collections` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `collections` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `collections_groups` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `devices` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `emergency_access` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `event` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `favorites` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `folders` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `folders_ciphers` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `groups` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `groups_users` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `invitations` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `org_policies` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `organizations` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `sends` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `twofactor` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `twofactor_incomplete` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `users` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `users_collections` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `users_organizations` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; SET foreign_key_checks = 1; /* verify CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci is on the place */
Now restart the app (via big button at the top of the terminal).
@girish , guess Vaultwarden 1.27.0 is a braking change and/or the patch before updating is required (as per above).
-
@JOduMonT said in no password when update to 1.11.0:
if I restore my vaultwarden on Version 2022.10.2 my password are their
as soon it updates and the container restart I lose all my password and I cannot import my backup- package: v1.10.2 == password
- package: v1.11.0 == no password
Wow! Thanks for the headsup! I checked with an instance and there seem to be no issues going from 1.10.2 to 1.11.0 on this one. Can somebody else reproduce this error?
-
@JOduMonT FYI my client apps says
Version 2022.12.0 (6060)
and my Cloudron app saysVaultwarden 1.27.0
andcom.github.bitwardenrs@1.11.0
: my passwords still being listed.Your client app seems old.
Not sure if if this is relevant or not. -
I had the same issue with 2 separate instances of cloudron.
But in case, I need to go back to a backup with version 1.9.2 -
That is odd, I also use Vaultwarden since.. years?
And I am currently runningcom.github.bitwardenrs@1.11.0
=>Vaultwarden 1.27.0
on multiple servers and clients.My Bitwarden Browser Addon has
Version: 2022.12.1
working.
The Web view it self works.Do you guys have any special setup?
If you could describe your usage a little more that could help.
Also make sure it's not some cache issue -
no idea if this is the same issue:
Empty password list in web view.Vaultwarden (unofficial Bitwarden server) Version 2022.12.0
Cloudron Package version v1.11.0Cloning from a previous package v1.10.2
2023 Bitwarden Inc. (Powered by Vaultwarden) Version 2022.10.2 shows me all my passwords.In this case, I did not use a browser plugin.
Crosstest with another instance (this time with a browser plugin): no problems.
-
It seems that my user account has lost the information about the organization. At https://vaultwarden.example.com/admin I can see the name of the organization (and the number of passwords stored there) created by my user account. But within a browser session there is no organization and therefore no passwords. Possible special case: I have no personal passwords. Exclusively passwords that belong to an organization.
-
I'm still not at all clear what the actual issue(s) people are facing is, but so far I've not noticed anything wrong with my Vaultwarden (on the latest Cloudron versions, which it sounds like everyone having issues also is).
It'd be useful if people could perhaps post screenshots of what they are (not) seeing
-
@jdaviescoates oh that is easy
empty password list is uglyReset/clone a previous package and log in with the same user account:
-
@luckow thanks! I thought that was what the issue was, but wasn't sure, but wanted to check if I was having the same issue (the idea of Vaultwarden having issues scares me because I'm so reliant on it)
I almost never use the web interface (just the mobile app and the browser plugin), but just checked and my passwords are listed fine in the web app too.
FWIW I have LOADS of personal passwords saved, plus some in some organisations too.
-
@luckow one of the teammates who use a browser plugin has no problem with the passwords. Now I have asked him to add me to the organization. Let's see if everything works as expected.
If that works, my best guess is: it's not a Cloudron package problem, it's an upstream problem. Maybe something with the master password/session/voodoo from Vaultwarden.
-
@JOduMonT just a double check to get a better idea of the setting for the reproducible support problem:
- do you use a browser plugin?
- do you have an organization?
- do you store the password only in the organization?
- is the organization and the number of passwords displayed in vaultwarden.example.org/admin? (no idea how to get access to /admin => https://docs.cloudron.io/apps/vaultwarden/)
-
mmh. I played a bit with restoring the previous version and updating to the latest version.
Long story short:
In the Cloudron logs (current app version) I get this error ->Jan 04 14:58:39 [2023-01-04 13:58:39.272][panic][ERROR] thread 'rocket-worker-thread' panicked at 'Error loading ciphers: DatabaseError(Unknown, "Illegal mix of collations (utf8mb4_unicode_ci,IMPLICIT) and (utf8mb4_0900_ai_ci,IMPLICIT) for operation '='")': src/db/models/cipher.rs:585 Jan 04 14:58:39 0: vaultwarden::init_logging::{{closure}} Jan 04 14:58:39 1: std::panicking::rust_panic_with_hook Jan 04 14:58:39 2: std::panicking::begin_panic_handler::{{closure}} Jan 04 14:58:39 3: std::sys_common::backtrace::__rust_end_short_backtrace Jan 04 14:58:39 4: rust_begin_unwind Jan 04 14:58:39 5: core::panicking::panic_fmt Jan 04 14:58:39 6: core::result::unwrap_failed Jan 04 14:58:39 7: tokio::runtime::context::exit_runtime Jan 04 14:58:39 8: tokio::runtime::scheduler::multi_thread::worker::block_in_place Jan 04 14:58:39 9: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll Jan 04 14:58:39 10: vaultwarden::api::core::ciphers::sync::into_info::monomorphized_function::{{closure}} Jan 04 14:58:39 11: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll Jan 04 14:58:39 12: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll Jan 04 14:58:39 13: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll Jan 04 14:58:39 14: tokio::loom::std::unsafe_cell::UnsafeCell<T>::with_mut Jan 04 14:58:39 15: tokio::runtime::task::core::Core<T,S>::poll Jan 04 14:58:39 16: tokio::runtime::task::harness::Harness<T,S>::poll Jan 04 14:58:39 17: tokio::runtime::scheduler::multi_thread::worker::Context::run_task Jan 04 14:58:39 18: tokio::runtime::scheduler::multi_thread::worker::Context::run Jan 04 14:58:39 19: tokio::macros::scoped_tls::ScopedKey<T>::set Jan 04 14:58:39 20: tokio::runtime::scheduler::multi_thread::worker::run Jan 04 14:58:39 21: tokio::loom::std::unsafe_cell::UnsafeCell<T>::with_mut Jan 04 14:58:39 22: tokio::runtime::task::core::Core<T,S>::poll Jan 04 14:58:39 23: tokio::runtime::task::harness::Harness<T,S>::poll Jan 04 14:58:39 24: tokio::runtime::blocking::pool::Inner::run Jan 04 14:58:39 25: std::sys_common::backtrace::__rust_begin_short_backtrace Jan 04 14:58:39 26: core::ops::function::FnOnce::call_once{{vtable.shim}} Jan 04 14:58:39 27: std::sys::unix::thread::Thread::new::thread_start Jan 04 14:58:39 28: <unknown> Jan 04 14:58:39 29: __clone Jan 04 14:58:39 Jan 04 14:58:39 [2023-01-04 13:58:39.272][_][ERROR] Handler sync panicked. Jan 04 14:58:39 [2023-01-04 13:58:39.272][_][WARN] A panic is treated as an internal server error. Jan 04 14:58:39 [2023-01-04 13:58:39.272][_][WARN] No 500 catcher registered. Using Rocket default. Jan 04 14:58:39 [2023-01-04 13:58:39.272][response][INFO] (sync) GET /api/sync?<data..> => 500 Internal Server Error
This entry occurs reproducibly as soon as my user account logs in.
-
-
@luckow thanks for digging this out - I just realized I have vaultwarden broken since the latest update, which is happened at 24th of Dec for me.
Here is the short instructions and extract based on @luckow findings:
On Web GUI:
- go the app
- click terminal
Now on the terminal:
echo ${CLOUDRON_MYSQL_DATABASE} # note the output - it's 35629ca3ac8992ec in my case mysql --user=${CLOUDRON_MYSQL_USERNAME} --password=${CLOUDRON_MYSQL_PASSWORD} --host=${CLOUDRON_MYSQL_HOST} ${CLOUDRON_MYSQL_DATABASE}
Now starts making database voddoo - make sure you have database backup first.
SELECT * FROM information_schema.SCHEMATA WHERE schema_name = "35629ca3ac8992ec"; SELECT CONCAT('ALTER TABLE `', TABLE_NAME,'` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;') AS CharSetConvert FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA="35629ca3ac8992ec" AND TABLE_TYPE="BASE TABLE"; ALTER DATABASE `35629ca3ac8992ec` CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; SET foreign_key_checks = 0; /* execute all queries from CharSetConvert output earlier here */ ALTER TABLE `__diesel_schema_migrations` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `attachments` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `ciphers` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `ciphers_collections` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `collections` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `collections_groups` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `devices` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `emergency_access` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `event` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `favorites` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `folders` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `folders_ciphers` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `groups` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `groups_users` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `invitations` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `org_policies` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `organizations` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `sends` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `twofactor` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `twofactor_incomplete` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `users` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `users_collections` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE `users_organizations` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; SET foreign_key_checks = 1; /* verify CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci is on the place */
Now restart the app (via big button at the top of the terminal).
@girish , guess Vaultwarden 1.27.0 is a braking change and/or the patch before updating is required (as per above).
-
@potemkin_ai I wonder why I seemingly haven't hit this issue though
-
@jdaviescoates random thought: how old is your cloudron instance?
Mine is from the around of the middle of the year 2022, migrated via export/import from an older one. -
@potemkin_ai I quite recently (Nov 2022) migrated to a new server, so I guess it's pretty new.
I'm also on Ubuntu 20.04.5 LTS, you?
-
@potemkin_ai good question
i recently installed cloudron on a fresh
"Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-56-generic x86_64)" instance installed at hetzner.