no password when update to 1.11.0

[nennogabriel]

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

[BrutalBirdie]

That is odd, I also use Vaultwarden since.. years?
And I am currently running com.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

[girish]

IIUC, after updating to 1.11.0 , the app is blank is it? i.e it has no contents at all? How are you verifying this? Using a browser plugin or by logging into the web app?

[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:

[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:

1. do you use a browser plugin?
2. do you have an organization?
3. do you store the password only in the organization?
4. 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.