[GH-ISSUE #2329] Unable to retrieve users from organizations #1227

New issue

Closed

opened 2026-03-03 02:07:17 +03:00 by kerem · 2 comments

kerem commented

2026-03-03 02:07:17 +03:00

Owner

Originally created by @Roultabie on GitHub (Feb 24, 2022).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/2329

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:

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 (Feb 24, 2022). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/2329 ## 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 ```

kerem closed this issue

2026-03-03 02:07:18 +03:00

kerem commented

2026-03-03 02:07:18 +03:00

Author

Owner

@BlackDex commented on GitHub (Feb 24, 2022):

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.

Make a backup of the database in case something goes wrong.
Run the following query

SELECT `user_uuid` FROM `users_organizations` WHERE `users_organizations`.`user_uuid` NOT IN (SELECT `uuid` FROM `users`);

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 (Feb 24, 2022): 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.

kerem commented

2026-03-03 02:07:18 +03:00

Author

Owner

@Roultabie commented on GitHub (Feb 24, 2022):

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 (Feb 24, 2022): 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.