Unable to retrieve users from organizations #1193

Closed
opened 2025-10-09 17:07:17 +03:00 by OVERLORD · 2 comments
Owner

Originally created by @Roultabie on GitHub.

Subject of the issue

Unable to retrieve users from organizations.

Environment

Vaultwarden version: 1.24.0 (upgraded from bitwarden_rs 1.19.0-a121cb6f)
Webvault version: 2.25.1
Virtual Machine: Ubuntu 20.04
Database: mariadb.
Builded with documentation.

Step to reproduce

It seems that doesn't work only for me.

Additional informations

Before the last update, it was impossible to retrieve the list of users, but, if I invited a user, the list would appear.
Since the last update this workaround does not work anymore.

Picture of example:

image

Troubleshooting data

[2022-02-24 12:34:07.865][panic][ERROR] thread 'unnamed' panicked at 'called `Option::unwrap()` on a `None` value': src/db/models/organization.rs:326
févr. 24 12:34:07 myServer vaultwarden[2804]:    0: vaultwarden::init_logging::{{closure}}
févr. 24 12:34:07 myServer vaultwarden[2804]:    1: std::panicking::rust_panic_with_hook
févr. 24 12:34:07 myServer vaultwarden[2804]:              at /rustc/bfe15646761a75f0259e204cab071565eed2b1e5/library/std/src/panicking.rs:695:17
févr. 24 12:34:07 myServer vaultwarden[2804]:    2: std::panicking::begin_panic_handler::{{closure}}
févr. 24 12:34:07 myServer vaultwarden[2804]:              at /rustc/bfe15646761a75f0259e204cab071565eed2b1e5/library/std/src/panicking.rs:579:13
févr. 24 12:34:07 myServer vaultwarden[2804]:    3: std::sys_common::backtrace::__rust_end_short_backtrace
févr. 24 12:34:07 myServer vaultwarden[2804]:              at /rustc/bfe15646761a75f0259e204cab071565eed2b1e5/library/std/src/sys_common/backtrace.rs:139:18
févr. 24 12:34:07 myServer vaultwarden[2804]:    4: rust_begin_unwind
févr. 24 12:34:07 myServer vaultwarden[2804]:              at /rustc/bfe15646761a75f0259e204cab071565eed2b1e5/library/std/src/panicking.rs:577:5
févr. 24 12:34:07 myServer vaultwarden[2804]:    5: core::panicking::panic_fmt
févr. 24 12:34:07 myServer vaultwarden[2804]:              at /rustc/bfe15646761a75f0259e204cab071565eed2b1e5/library/core/src/panicking.rs:135:14
févr. 24 12:34:07 myServer vaultwarden[2804]:    6: core::panicking::panic
févr. 24 12:34:07 myServer vaultwarden[2804]:              at /rustc/bfe15646761a75f0259e204cab071565eed2b1e5/library/core/src/panicking.rs:48:5
févr. 24 12:34:07 myServer vaultwarden[2804]:    7: vaultwarden::db::models::organization::UserOrganization::to_json_user_details
févr. 24 12:34:07 myServer vaultwarden[2804]:    8: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
févr. 24 12:34:07 myServer vaultwarden[2804]:    9: vaultwarden::api::core::organizations::rocket_route_fn_get_org_users
févr. 24 12:34:07 myServer vaultwarden[2804]:   10: <F as rocket::handler::Handler>::handle
févr. 24 12:34:07 myServer vaultwarden[2804]:   11: rocket::rocket::Rocket::route_and_process
févr. 24 12:34:07 myServer vaultwarden[2804]:   12: <rocket::rocket::Rocket as hyper::server::Handler>::handle
févr. 24 12:34:07 myServer vaultwarden[2804]:   13: hyper::server::Worker<H>::handle_connection
févr. 24 12:34:07 myServer vaultwarden[2804]:   14: std::sys_common::backtrace::__rust_begin_short_backtrace
févr. 24 12:34:07 myServer vaultwarden[2804]:   15: core::ops::function::FnOnce::call_once{{vtable.shim}}
févr. 24 12:34:07 myServer vaultwarden[2804]:   16: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
févr. 24 12:34:07 myServer vaultwarden[2804]:              at /rustc/bfe15646761a75f0259e204cab071565eed2b1e5/library/alloc/src/boxed.rs:1854:9
févr. 24 12:34:07 myServer vaultwarden[2804]:       <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
févr. 24 12:34:07 myServer vaultwarden[2804]:              at /rustc/bfe15646761a75f0259e204cab071565eed2b1e5/library/alloc/src/boxed.rs:1854:9
févr. 24 12:34:07 myServer vaultwarden[2804]:       std::sys::unix::thread::Thread::new::thread_start
févr. 24 12:34:07 myServer vaultwarden[2804]:              at /rustc/bfe15646761a75f0259e204cab071565eed2b1e5/library/std/src/sys/unix/thread.rs:108:17
févr. 24 12:34:07 myServer vaultwarden[2804]:   17: start_thread
févr. 24 12:34:07 myServer vaultwarden[2804]:   18: clone
Originally created by @Roultabie on GitHub. ## Subject of the issue Unable to retrieve users from organizations. ## Environment Vaultwarden version: 1.24.0 (upgraded from bitwarden_rs 1.19.0-a121cb6f) Webvault version: 2.25.1 Virtual Machine: Ubuntu 20.04 Database: mariadb. Builded with documentation. ## Step to reproduce It seems that doesn't work only for me. ## Additional informations Before the last update, it was impossible to retrieve the list of users, but, if I invited a user, the list would appear. Since the last update this workaround does not work anymore. ### Picture of example: ![image](https://user-images.githubusercontent.com/1756947/155541672-345f414c-f713-41d5-8248-2091df81edc0.png) ## Troubleshooting data ``` [2022-02-24 12:34:07.865][panic][ERROR] thread 'unnamed' panicked at 'called `Option::unwrap()` on a `None` value': src/db/models/organization.rs:326 févr. 24 12:34:07 myServer vaultwarden[2804]: 0: vaultwarden::init_logging::{{closure}} févr. 24 12:34:07 myServer vaultwarden[2804]: 1: std::panicking::rust_panic_with_hook févr. 24 12:34:07 myServer vaultwarden[2804]: at /rustc/bfe15646761a75f0259e204cab071565eed2b1e5/library/std/src/panicking.rs:695:17 févr. 24 12:34:07 myServer vaultwarden[2804]: 2: std::panicking::begin_panic_handler::{{closure}} févr. 24 12:34:07 myServer vaultwarden[2804]: at /rustc/bfe15646761a75f0259e204cab071565eed2b1e5/library/std/src/panicking.rs:579:13 févr. 24 12:34:07 myServer vaultwarden[2804]: 3: std::sys_common::backtrace::__rust_end_short_backtrace févr. 24 12:34:07 myServer vaultwarden[2804]: at /rustc/bfe15646761a75f0259e204cab071565eed2b1e5/library/std/src/sys_common/backtrace.rs:139:18 févr. 24 12:34:07 myServer vaultwarden[2804]: 4: rust_begin_unwind févr. 24 12:34:07 myServer vaultwarden[2804]: at /rustc/bfe15646761a75f0259e204cab071565eed2b1e5/library/std/src/panicking.rs:577:5 févr. 24 12:34:07 myServer vaultwarden[2804]: 5: core::panicking::panic_fmt févr. 24 12:34:07 myServer vaultwarden[2804]: at /rustc/bfe15646761a75f0259e204cab071565eed2b1e5/library/core/src/panicking.rs:135:14 févr. 24 12:34:07 myServer vaultwarden[2804]: 6: core::panicking::panic févr. 24 12:34:07 myServer vaultwarden[2804]: at /rustc/bfe15646761a75f0259e204cab071565eed2b1e5/library/core/src/panicking.rs:48:5 févr. 24 12:34:07 myServer vaultwarden[2804]: 7: vaultwarden::db::models::organization::UserOrganization::to_json_user_details févr. 24 12:34:07 myServer vaultwarden[2804]: 8: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter févr. 24 12:34:07 myServer vaultwarden[2804]: 9: vaultwarden::api::core::organizations::rocket_route_fn_get_org_users févr. 24 12:34:07 myServer vaultwarden[2804]: 10: <F as rocket::handler::Handler>::handle févr. 24 12:34:07 myServer vaultwarden[2804]: 11: rocket::rocket::Rocket::route_and_process févr. 24 12:34:07 myServer vaultwarden[2804]: 12: <rocket::rocket::Rocket as hyper::server::Handler>::handle févr. 24 12:34:07 myServer vaultwarden[2804]: 13: hyper::server::Worker<H>::handle_connection févr. 24 12:34:07 myServer vaultwarden[2804]: 14: std::sys_common::backtrace::__rust_begin_short_backtrace févr. 24 12:34:07 myServer vaultwarden[2804]: 15: core::ops::function::FnOnce::call_once{{vtable.shim}} févr. 24 12:34:07 myServer vaultwarden[2804]: 16: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once févr. 24 12:34:07 myServer vaultwarden[2804]: at /rustc/bfe15646761a75f0259e204cab071565eed2b1e5/library/alloc/src/boxed.rs:1854:9 févr. 24 12:34:07 myServer vaultwarden[2804]: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once févr. 24 12:34:07 myServer vaultwarden[2804]: at /rustc/bfe15646761a75f0259e204cab071565eed2b1e5/library/alloc/src/boxed.rs:1854:9 févr. 24 12:34:07 myServer vaultwarden[2804]: std::sys::unix::thread::Thread::new::thread_start févr. 24 12:34:07 myServer vaultwarden[2804]: at /rustc/bfe15646761a75f0259e204cab071565eed2b1e5/library/std/src/sys/unix/thread.rs:108:17 févr. 24 12:34:07 myServer vaultwarden[2804]: 17: start_thread févr. 24 12:34:07 myServer vaultwarden[2804]: 18: clone ```
Author
Owner

@Roultabie commented on GitHub:

A big thank you !

The query returned me five user_uuid, after deleting them, problem was solved.

I had a problem in deleting users recently (PEBKAC), that must have been the cause.

@Roultabie commented on GitHub: A big thank you ! The query returned me five user_uuid, after deleting them, problem was solved. I had a problem in deleting users recently (PEBKAC), that must have been the cause.
Author
Owner

@BlackDex commented on GitHub:

This almost looks like a corrupted database, or maybe even an invalid schema, or some user which wasn't fully removed or something. I think it is the latter one which is the actual culprit here.

Try to do the following.

  1. Make a backup of the database in case something goes wrong.
  2. Run the following query
SELECT `user_uuid` FROM `users_organizations` WHERE `users_organizations`.`user_uuid` NOT IN (SELECT `uuid` FROM `users`);
  1. If you get any output, that is what is causing the issue. You need to remove those records and probably also from users_collections, folders and favorites tables. I would not touch the ciphers table, since it could have shared passwords.

Also, try to check if you have ForeignKey check enabled on the database, since that is what should have prevented this.

@BlackDex commented on GitHub: This almost looks like a corrupted database, or maybe even an invalid schema, or some user which wasn't fully removed or something. I think it is the latter one which is the actual culprit here. Try to do the following. 1. Make a backup of the database in case something goes wrong. 2. Run the following query ```sql SELECT `user_uuid` FROM `users_organizations` WHERE `users_organizations`.`user_uuid` NOT IN (SELECT `uuid` FROM `users`); ``` 3. If you get any output, that is what is causing the issue. You need to remove those records and probably also from `users_collections`, `folders` and `favorites` tables. I would not touch the `ciphers` table, since it could have shared passwords. Also, try to check if you have ForeignKey check enabled on the database, since that is what should have prevented this.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/vaultwarden#1193