Closing this as a duplicate of #2484 (After re-opening it).
Please update that issue with the same information so that we can keep all together.
@BlackDex commented on GitHub (May 25, 2022):
Closing this as a duplicate of #2484 (After re-opening it).
Please update that issue with the same information so that we can keep all together.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @PeterRob on GitHub (May 25, 2022).
Subject of the issue
After upgrading to version 1.25.0 the vault appears to be empty when opened in the web browser
This is similar to issue #2484 that was closed and subsequently 2 people reported the same problem after closure https://github.com/dani-garcia/vaultwarden/issues/2484
Deployment environment
Your environment (Generated via diagnostics page)
Config (Generated via diagnostics page)
Show Running Config
Environment settings which are overridden: DOMAIN, SIGNUPS_ALLOWED, SIGNUPS_VERIFY, SIGNUPS_VERIFY_RESEND_TIME, SIGNUPS_VERIFY_RESEND_LIMIT, INVITATIONS_ALLOWED, SHOW_PASSWORD_HINT, ADMIN_TOKEN, DISABLE_ADMIN_TOKEN, SMTP_HOST, SMTP_SECURITY, SMTP_PORT, SMTP_FROM, SMTP_FROM_NAME, SMTP_USERNAME, SMTP_PASSWORD, SMTP_TIMEOUT
Install method:
Built from source
Clients used:
Browser
Reverse proxy and version:
Caddy
MySQL/MariaDB or PostgreSQL version:
Mariadb
Other relevant details:
Steps to reproduce
Expected behaviour
The vault appears to be empty
Actual behaviour
The vault to be available in the web browser
Troubleshooting data
Vaultwarden log:
thread 'rocket-worker-thread' panicked at 'Error loading attachments: DatabaseError(__Unknown, "Commands out of sync; you can't run this command now")': src/db/models/attachment.rs:196
0: backtrace::backtrace::trace
1: backtrace::capture::Backtrace::new
2: vaultwarden::init_logging::{{closure}}
3: std::panicking::rust_panic_with_hook
4: std::panicking::begin_panic_handler::{{closure}}
5: std::sys_common::backtrace::__rust_end_short_backtrace
6: rust_begin_unwind
7: core::panicking::panic_fmt
8: core::result::unwrap_failed
9: tokio::runtime::enter::exit
10: tokio::runtime::thread_pool::worker::block_in_place
11: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
12: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
13: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
14: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
15: tokio::runtime::task::core::CoreStage::poll
16: tokio::runtime::task::harness::poll_future
17: tokio::runtime::task::harness::Harness<T,S>::poll
18: std::thread::local::LocalKey::with
19: tokio::runtime::thread_pool::worker::Context::run_task
20: tokio::runtime::thread_pool::worker::Context::run
21: tokio::macros::scoped_tls::ScopedKey::set
22: tokio::runtime::thread_pool::worker::run
23: <tokio::runtime::blocking::task::BlockingTask as core::future::future::Future>::poll
24: tokio::runtime::task::harness::Harness<T,S>::poll
25: tokio::runtime::blocking::pool::Inner::run
26: std::sys_common::backtrace::__rust_begin_short_backtrace
27: core::ops::function::FnOnce::call_once{{vtable.shim}}
28: std::sys::unix::thread::Thread::new::thread_start
@BlackDex commented on GitHub (May 25, 2022):
Closing this as a duplicate of #2484 (After re-opening it).
Please update that issue with the same information so that we can keep all together.