no password when update to 1.11.0

luckow

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.0

Cloning 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.

luckow

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.

jdaviescoates

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

luckow

@jdaviescoates oh that is easy

empty password list is ugly

Reset/clone a previous package and log in with the same user account:
Bildschirmfoto vom 2023-01-04 00-05-30.png

jdaviescoates

@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

@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.

luckow

@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/)

luckow

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

@luckow I'm not alone -> https://github.com/dani-garcia/vaultwarden/issues/2958#issuecomment-1336718098

potemkin_ai

@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).

jdaviescoates

@potemkin_ai I wonder why I seemingly haven't hit this issue though

potemkin_ai

@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.

jdaviescoates

@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?

luckow

@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.

necrevistonnezr

@jdaviescoates said in no password when update to 1.11.0:

@potemkin_ai I wonder why I seemingly haven't hit this issue though

Me neither. My instance is 4-5 years old including Ubuntu migrations from 18.04 -> 20.04 -> 22.04, had Bitwarden since the beginning incl. organizations.

potemkin_ai

@jdaviescoates , @luckow , @necrevistonnezr , it was just a wild guess - it feels like it must be somehow connected to the software updates, since it impact only a small fraction of the users.

Might be just some random bug...

girish

Our company and my personal installation is quite old as well (~4 years or so). I wonder why we don't hit this. Let me investigate quickly to see if this is something obvious.

potemkin_ai

@girish thanks for prompt reaction!

JOduMonT

@luckow said in no password when update to 1.11.0:

do you use a browser plugin?

password disappears after updating via the browser (webapp) and the app in the browser (plugin) and in my androids don't sync anymore

do you have an organization?

NO

do you store the password only in the organization?

NO

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/)

NO

my Cloudron is update to date on an Ubuntu 20.04LTS; no change or weird configuration as been done.

JOduMonT

@jdaviescoates said in no password when update to 1.11.0:

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).

with 1.26.0 I have password
while with 1.27.0 I don't have password

PASSWORD + SYNC OK

App Title and VersionVaultwarden 1.26.0
App ID4584d250-1515-4380-be5b-87a4ab3cd92d
Package Repositorycore
Package Versioncom.github.bitwardenrs@1.10.2
Last Updated4 days ago

sorry for your eyes; my internet is too bad right now for uploading screenshot

NO PASSWORD + SYNC FAIL

App Title and VersionVaultwarden 1.27.0
App ID4584d250-1515-4380-be5b-87a4ab3cd92d
Package Repositorycore
Package Versioncom.github.bitwardenrs@1.11.0
Last Updated2 minutes ago

Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.

Cloudron Forum

no password when update to 1.11.0

PASSWORD + SYNC OK

NO PASSWORD + SYNC FAIL