starred/vaultwarden
1
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-02-05 00:29:40 +03:00
Code Issues 32 Packages Projects Releases 10 Wiki Activity

Unable to retrieve users from organizations #1222

New Issue
Closed
opened 2026-02-05 00:19:52 +03:00 by OVERLORD · 2 comments
OVERLORD commented 2026-02-05 00:19:52 +03:00
Owner
Copy Link

Originally created by @Roultabie on GitHub (Feb 24, 2022).

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 (Feb 24, 2022). ## 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 ```
OVERLORD commented 2026-02-05 00:20:03 +03:00
Author
Owner
Copy Link

@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
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 (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.
OVERLORD commented 2026-02-05 00:20:08 +03:00
Author
Owner
Copy Link

@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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
SSO
Third party
better for forum
bug
bug
documentation
duplicate
enhancement
future Vault
future Vault
future Vault
good first issue
help wanted
low priority
notes
pull-request
Mirrored from GitHub Pull Request
 question
troubleshooting
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/vaultwarden#1222
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?