starred/vaultwarden
1
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden.git synced 2025-12-06 09:13:03 +03:00
Code Issues 429 Packages Projects Releases 10 Wiki Activity

cannot start docker container v1.25.0 #1136

New Issue
Closed
opened 2025-10-09 17:05:09 +03:00 by OVERLORD · 17 comments
OVERLORD commented 2025-10-09 17:05:09 +03:00
Owner
Copy Link

Originally created by @bassarf on GitHub.

Subject of the issue

When I try to start my docker container it does not start.

Deployment environment

  • vaultwarden version: 1.25.0

  • Install method: Docker

  • Other relevant details:

Steps to reproduce

Starting the container via:

docker run -d --name vaultwarden \
  -e ROCKET_TLS='{certs="/ssl/live/<domain>/fullchain.pem",key="/ssl/live/<domain>/privkey.pem"}' \
  -e SIGNUPS_ALLOWED=false \
  -e ADMIN_TOKEN=<token string> \
  -v /etc/letsencrypt/:/ssl/ \
  -v /home/<user>/programme/vaultwarden/vw-data/:/data/ \
  -p <port>:80 \
  --restart=unless-stopped \
  vaultwarden/server:latest

Expected behaviour

container should start

Actual behaviour

container does not start correctly. When typing docker logs vaultwarden I get the following error

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

when starting with an additional RUST_BACKTRACE=1 I get the following

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::result::unwrap_failed
   3: tokio::time::driver::Driver<P>::new
   4: tokio::runtime::driver::Driver::new
   5: tokio::runtime::builder::Builder::build
   6: rocket::async_main
   7: vaultwarden::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::result::unwrap_failed
   3: tokio::time::driver::Driver<P>::new
   4: tokio::runtime::driver::Driver::new
   5: tokio::runtime::builder::Builder::build
   6: rocket::async_main
   7: vaultwarden::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Troubleshooting data

Originally created by @bassarf on GitHub. <!-- # ### NOTE: Please update to the latest version of vaultwarden before reporting an issue! This saves you and us a lot of time and troubleshooting. See: * https://github.com/dani-garcia/vaultwarden/issues/1180 * https://github.com/dani-garcia/vaultwarden/wiki/Updating-the-vaultwarden-image # ### --> <!-- Please fill out the following template to make solving your problem easier and faster for us. This is only a guideline. If you think that parts are unnecessary for your issue, feel free to remove them. Remember to hide/redact personal or confidential information, such as passwords, IP addresses, and DNS names as appropriate. --> ### Subject of the issue <!-- Describe your issue here. --> When I try to start my docker container it does not start. ### Deployment environment <!-- ========================================================================================= Preferably, use the `Generate Support String` button on the admin page's Diagnostics tab. That will auto-generate most of the info requested in this section. ========================================================================================= --> <!-- The version number, obtained from the logs (at startup) or the admin diagnostics page --> <!-- This is NOT the version number shown on the web vault, which is versioned separately from vaultwarden --> <!-- Remember to check if your issue exists on the latest version first! --> * vaultwarden version: 1.25.0 <!-- How the server was installed: Docker image, OS package, built from source, etc. --> * Install method: Docker * Other relevant details: ### Steps to reproduce <!-- Tell us how to reproduce this issue. What parameters did you set (differently from the defaults) and how did you start vaultwarden? --> Starting the container via: ``` docker run -d --name vaultwarden \ -e ROCKET_TLS='{certs="/ssl/live/<domain>/fullchain.pem",key="/ssl/live/<domain>/privkey.pem"}' \ -e SIGNUPS_ALLOWED=false \ -e ADMIN_TOKEN=<token string> \ -v /etc/letsencrypt/:/ssl/ \ -v /home/<user>/programme/vaultwarden/vw-data/:/data/ \ -p <port>:80 \ --restart=unless-stopped \ vaultwarden/server:latest ``` ### Expected behaviour <!-- Tell us what you expected to happen --> container should start ### Actual behaviour <!-- Tell us what actually happened --> container does not start correctly. When typing `docker logs vaultwarden` I get the following error ``` thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` when starting with an additional `RUST_BACKTRACE=1` I get the following ``` thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62 stack backtrace: 0: rust_begin_unwind 1: core::panicking::panic_fmt 2: core::result::unwrap_failed 3: tokio::time::driver::Driver<P>::new 4: tokio::runtime::driver::Driver::new 5: tokio::runtime::builder::Builder::build 6: rocket::async_main 7: vaultwarden::main note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62 stack backtrace: 0: rust_begin_unwind 1: core::panicking::panic_fmt 2: core::result::unwrap_failed 3: tokio::time::driver::Driver<P>::new 4: tokio::runtime::driver::Driver::new 5: tokio::runtime::builder::Builder::build 6: rocket::async_main 7: vaultwarden::main note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. ``` ### Troubleshooting data <!-- Share any log files, screenshots, or other relevant troubleshooting data -->
OVERLORD added the bugtroubleshooting labels 2025-10-09 17:05:09 +03:00
OVERLORD commented 2025-10-09 17:05:11 +03:00
Author
Owner
Copy Link

@arctic-alpaca commented on GitHub:

This might be related to this issue: https://github.com/moby/moby/issues/40734

If it is, running the container as privileged or seccomp=unconfined should work as a quick and dirty work-around. More permanent solutions are discussed in the linked issue and the other issues linked there.

@arctic-alpaca commented on GitHub: This might be related to this issue: https://github.com/moby/moby/issues/40734 If it is, running the container as privileged or seccomp=unconfined should work as a quick and dirty work-around. More permanent solutions are discussed in the linked issue and the other issues linked there.
OVERLORD commented 2025-10-09 17:05:11 +03:00
Author
Owner
Copy Link

@moduraziel commented on GitHub:

For what it's worth, I am redeploying vaultwarden after trying it out a couple days ago (and it working) and I am having the exact same errors. Something wrong with the image maybe?

@moduraziel commented on GitHub: For what it's worth, I am redeploying vaultwarden after trying it out a couple days ago (and it working) and I am having the exact same errors. Something wrong with the image maybe?
OVERLORD commented 2025-10-09 17:05:11 +03:00
Author
Owner
Copy Link

@oven8Mitts commented on GitHub:

Also getting this issue on:
Raspberry Pi 4 Model B Rev 1.1, running Raspbian Buster
ARM v7

Vaultwarden info:
sha256:f3ebede27f1cf5e78373c3c4a429cf1fdd8d6b13528a2b9ca4fb3cb7cc681ba9
vaultwarden/server:latest

Here's my complete trace with debug on:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62
stack backtrace:
   0:   0xb28d78 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::had5730c67ab50e4d
   1:   0x607090 - core::fmt::write::ha42b2480a34f3eb5
   2:   0xb21fe4 - std::io::Write::write_fmt::hfa663667fab44c82
   3:   0xb2ac60 - std::panicking::default_hook::{{closure}}::h6e8d770966f585fd
   4:   0xb2a8f0 - std::panicking::default_hook::h71b5cfb8a06cd56f
   5:   0xb2b1dc - std::panicking::rust_panic_with_hook::hfc13f45907194734
   6:   0xb2b0dc - std::panicking::begin_panic_handler::{{closure}}::h8bd28c15b24c2fb7
   7:   0xb29390 - std::sys_common::backtrace::__rust_end_short_backtrace::hef7cb296473d0b87
   8:   0xb2ae6c - rust_begin_unwind
   9:   0x5812f4 - core::panicking::panic_fmt::hc45184285ee465d2
  10:   0x5813c8 - core::result::unwrap_failed::h51f4224fc12cbf0e
  11:   0xb70a88 - tokio::time::driver::Driver<P>::new::hfb66ef6768de0218
  12:   0xb5f658 - tokio::runtime::driver::Driver::new::hb1ee45257e549b73
  13:   0xb5f124 - tokio::runtime::builder::Builder::build::hed4ce3523a05a186
  14:   0xe94f0c - rocket::async_main::h077ba2654118e619
  15:   0xde5fbc - vaultwarden::main::h433acfc7f8dab814
  16:   0xe0259c - std::sys_common::backtrace::__rust_begin_short_backtrace::heeb0eb3b70d82df1
  17:  0x1198670 - std::rt::lang_start::{{closure}}::ha2f1a90a8484b316
  18:   0xb1b170 - std::rt::lang_start_internal::ha117b08a7dcebcaf
  19:   0xde5ff0 - main
  20: 0xb6b69a20 - __libc_start_main
@oven8Mitts commented on GitHub: Also getting this issue on: Raspberry Pi 4 Model B Rev 1.1, running Raspbian Buster ARM v7 Vaultwarden info: sha256:f3ebede27f1cf5e78373c3c4a429cf1fdd8d6b13528a2b9ca4fb3cb7cc681ba9 vaultwarden/server:latest Here's my complete trace with debug on: ``` thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62 stack backtrace: 0: 0xb28d78 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::had5730c67ab50e4d 1: 0x607090 - core::fmt::write::ha42b2480a34f3eb5 2: 0xb21fe4 - std::io::Write::write_fmt::hfa663667fab44c82 3: 0xb2ac60 - std::panicking::default_hook::{{closure}}::h6e8d770966f585fd 4: 0xb2a8f0 - std::panicking::default_hook::h71b5cfb8a06cd56f 5: 0xb2b1dc - std::panicking::rust_panic_with_hook::hfc13f45907194734 6: 0xb2b0dc - std::panicking::begin_panic_handler::{{closure}}::h8bd28c15b24c2fb7 7: 0xb29390 - std::sys_common::backtrace::__rust_end_short_backtrace::hef7cb296473d0b87 8: 0xb2ae6c - rust_begin_unwind 9: 0x5812f4 - core::panicking::panic_fmt::hc45184285ee465d2 10: 0x5813c8 - core::result::unwrap_failed::h51f4224fc12cbf0e 11: 0xb70a88 - tokio::time::driver::Driver<P>::new::hfb66ef6768de0218 12: 0xb5f658 - tokio::runtime::driver::Driver::new::hb1ee45257e549b73 13: 0xb5f124 - tokio::runtime::builder::Builder::build::hed4ce3523a05a186 14: 0xe94f0c - rocket::async_main::h077ba2654118e619 15: 0xde5fbc - vaultwarden::main::h433acfc7f8dab814 16: 0xe0259c - std::sys_common::backtrace::__rust_begin_short_backtrace::heeb0eb3b70d82df1 17: 0x1198670 - std::rt::lang_start::{{closure}}::ha2f1a90a8484b316 18: 0xb1b170 - std::rt::lang_start_internal::ha117b08a7dcebcaf 19: 0xde5ff0 - main 20: 0xb6b69a20 - __libc_start_main ```
OVERLORD commented 2025-10-09 17:05:12 +03:00
Author
Owner
Copy Link

@BlackDex commented on GitHub:

Looks like the container isn't allowed to get the current time or something. Could you try to use RUST_BACKTRACE=full together with LOG_LEVEL=debug?

What is your Host OS?

@BlackDex commented on GitHub: Looks like the container isn't allowed to get the current time or something. Could you try to use `RUST_BACKTRACE=full` together with `LOG_LEVEL=debug`? What is your Host OS?
OVERLORD commented 2025-10-09 17:05:12 +03:00
Author
Owner
Copy Link

@bassarf commented on GitHub:

Looks like the container isn't allowed to get the current time or something. Could you try to use RUST_BACKTRACE=full together with LOG_LEVEL=debug?

What is your Host OS?

Thank you for your fast reply. Here is the log output with RUST_BACKTRACE=full and LOG_LEVEL=debug (Its basically the same as from @99ytrewq991)

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62
stack backtrace:
   0:   0xb58d78 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::had5730c67ab50e4d
   1:   0x637090 - core::fmt::write::ha42b2480a34f3eb5
   2:   0xb51fe4 - std::io::Write::write_fmt::hfa663667fab44c82
   3:   0xb5ac60 - std::panicking::default_hook::{{closure}}::h6e8d770966f585fd
   4:   0xb5a8f0 - std::panicking::default_hook::h71b5cfb8a06cd56f
   5:   0xb5b1dc - std::panicking::rust_panic_with_hook::hfc13f45907194734
   6:   0xb5b0dc - std::panicking::begin_panic_handler::{{closure}}::h8bd28c15b24c2fb7
   7:   0xb59390 - std::sys_common::backtrace::__rust_end_short_backtrace::hef7cb296473d0b87
   8:   0xb5ae6c - rust_begin_unwind
   9:   0x5b12f4 - core::panicking::panic_fmt::hc45184285ee465d2
  10:   0x5b13c8 - core::result::unwrap_failed::h51f4224fc12cbf0e
  11:   0xba0a88 - tokio::time::driver::Driver<P>::new::hfb66ef6768de0218
  12:   0xb8f658 - tokio::runtime::driver::Driver::new::hb1ee45257e549b73
  13:   0xb8f124 - tokio::runtime::builder::Builder::build::hed4ce3523a05a186
  14:   0xec4f0c - rocket::async_main::h077ba2654118e619
  15:   0xe15fbc - vaultwarden::main::h433acfc7f8dab814
  16:   0xe3259c - std::sys_common::backtrace::__rust_begin_short_backtrace::heeb0eb3b70d82df1
  17:  0x11c8670 - std::rt::lang_start::{{closure}}::ha2f1a90a8484b316
  18:   0xb4b170 - std::rt::lang_start_internal::ha117b08a7dcebcaf
  19:   0xe15ff0 - main
  20: 0xb6ac6a20 - __libc_start_main
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62
stack backtrace:
   0:   0xaf8d78 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::had5730c67ab50e4d
   1:   0x5d7090 - core::fmt::write::ha42b2480a34f3eb5
   2:   0xaf1fe4 - std::io::Write::write_fmt::hfa663667fab44c82
   3:   0xafac60 - std::panicking::default_hook::{{closure}}::h6e8d770966f585fd
   4:   0xafa8f0 - std::panicking::default_hook::h71b5cfb8a06cd56f
   5:   0xafb1dc - std::panicking::rust_panic_with_hook::hfc13f45907194734
   6:   0xafb0dc - std::panicking::begin_panic_handler::{{closure}}::h8bd28c15b24c2fb7
   7:   0xaf9390 - std::sys_common::backtrace::__rust_end_short_backtrace::hef7cb296473d0b87
   8:   0xafae6c - rust_begin_unwind
   9:   0x5512f4 - core::panicking::panic_fmt::hc45184285ee465d2
  10:   0x5513c8 - core::result::unwrap_failed::h51f4224fc12cbf0e
  11:   0xb40a88 - tokio::time::driver::Driver<P>::new::hfb66ef6768de0218
  12:   0xb2f658 - tokio::runtime::driver::Driver::new::hb1ee45257e549b73
  13:   0xb2f124 - tokio::runtime::builder::Builder::build::hed4ce3523a05a186
  14:   0xe64f0c - rocket::async_main::h077ba2654118e619
  15:   0xdb5fbc - vaultwarden::main::h433acfc7f8dab814
  16:   0xdd259c - std::sys_common::backtrace::__rust_begin_short_backtrace::heeb0eb3b70d82df1
  17:  0x1168670 - std::rt::lang_start::{{closure}}::ha2f1a90a8484b316
  18:   0xaeb170 - std::rt::lang_start_internal::ha117b08a7dcebcaf
  19:   0xdb5ff0 - main
  20: 0xb6b1aa20 - __libc_start_main

(I do not know why docker logs vaultwarden gives me the same stacktrace twice)

I also run it on a Raspberry PI 4 with buster

@bassarf commented on GitHub: > Looks like the container isn't allowed to get the current time or something. Could you try to use `RUST_BACKTRACE=full` together with `LOG_LEVEL=debug`? > > What is your Host OS? Thank you for your fast reply. Here is the log output with `RUST_BACKTRACE=full` and `LOG_LEVEL=debug` (Its basically the same as from @99ytrewq991) ``` thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62 stack backtrace: 0: 0xb58d78 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::had5730c67ab50e4d 1: 0x637090 - core::fmt::write::ha42b2480a34f3eb5 2: 0xb51fe4 - std::io::Write::write_fmt::hfa663667fab44c82 3: 0xb5ac60 - std::panicking::default_hook::{{closure}}::h6e8d770966f585fd 4: 0xb5a8f0 - std::panicking::default_hook::h71b5cfb8a06cd56f 5: 0xb5b1dc - std::panicking::rust_panic_with_hook::hfc13f45907194734 6: 0xb5b0dc - std::panicking::begin_panic_handler::{{closure}}::h8bd28c15b24c2fb7 7: 0xb59390 - std::sys_common::backtrace::__rust_end_short_backtrace::hef7cb296473d0b87 8: 0xb5ae6c - rust_begin_unwind 9: 0x5b12f4 - core::panicking::panic_fmt::hc45184285ee465d2 10: 0x5b13c8 - core::result::unwrap_failed::h51f4224fc12cbf0e 11: 0xba0a88 - tokio::time::driver::Driver<P>::new::hfb66ef6768de0218 12: 0xb8f658 - tokio::runtime::driver::Driver::new::hb1ee45257e549b73 13: 0xb8f124 - tokio::runtime::builder::Builder::build::hed4ce3523a05a186 14: 0xec4f0c - rocket::async_main::h077ba2654118e619 15: 0xe15fbc - vaultwarden::main::h433acfc7f8dab814 16: 0xe3259c - std::sys_common::backtrace::__rust_begin_short_backtrace::heeb0eb3b70d82df1 17: 0x11c8670 - std::rt::lang_start::{{closure}}::ha2f1a90a8484b316 18: 0xb4b170 - std::rt::lang_start_internal::ha117b08a7dcebcaf 19: 0xe15ff0 - main 20: 0xb6ac6a20 - __libc_start_main thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', library/std/src/sys/unix/time.rs:353:62 stack backtrace: 0: 0xaf8d78 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::had5730c67ab50e4d 1: 0x5d7090 - core::fmt::write::ha42b2480a34f3eb5 2: 0xaf1fe4 - std::io::Write::write_fmt::hfa663667fab44c82 3: 0xafac60 - std::panicking::default_hook::{{closure}}::h6e8d770966f585fd 4: 0xafa8f0 - std::panicking::default_hook::h71b5cfb8a06cd56f 5: 0xafb1dc - std::panicking::rust_panic_with_hook::hfc13f45907194734 6: 0xafb0dc - std::panicking::begin_panic_handler::{{closure}}::h8bd28c15b24c2fb7 7: 0xaf9390 - std::sys_common::backtrace::__rust_end_short_backtrace::hef7cb296473d0b87 8: 0xafae6c - rust_begin_unwind 9: 0x5512f4 - core::panicking::panic_fmt::hc45184285ee465d2 10: 0x5513c8 - core::result::unwrap_failed::h51f4224fc12cbf0e 11: 0xb40a88 - tokio::time::driver::Driver<P>::new::hfb66ef6768de0218 12: 0xb2f658 - tokio::runtime::driver::Driver::new::hb1ee45257e549b73 13: 0xb2f124 - tokio::runtime::builder::Builder::build::hed4ce3523a05a186 14: 0xe64f0c - rocket::async_main::h077ba2654118e619 15: 0xdb5fbc - vaultwarden::main::h433acfc7f8dab814 16: 0xdd259c - std::sys_common::backtrace::__rust_begin_short_backtrace::heeb0eb3b70d82df1 17: 0x1168670 - std::rt::lang_start::{{closure}}::ha2f1a90a8484b316 18: 0xaeb170 - std::rt::lang_start_internal::ha117b08a7dcebcaf 19: 0xdb5ff0 - main 20: 0xb6b1aa20 - __libc_start_main ``` (I do not know why `docker logs vaultwarden` gives me the same stacktrace twice) I also run it on a Raspberry PI 4 with buster
OVERLORD commented 2025-10-09 17:05:13 +03:00
Author
Owner
Copy Link

@BlackDex commented on GitHub:

Maybe a strange thing, but could you both try the Alpine image maybe?

@BlackDex commented on GitHub: Maybe a strange thing, but could you both try the Alpine image maybe?
OVERLORD commented 2025-10-09 17:05:14 +03:00
Author
Owner
Copy Link

@bassarf commented on GitHub:

Im still learning my way around Docker/Portainer...how do I add this flag to my container? Is it just an ENV variable? And how do I access the Alpine image?

in order to use the alpine image you just use vaultwarden/server:alpine instead of vaultwarden/server:latest.
in order to use the flag you just add --security-opt seccomp=unconfined to your docker run command.

@bassarf commented on GitHub: > Im still learning my way around Docker/Portainer...how do I add this flag to my container? Is it just an ENV variable? And how do I access the Alpine image? in order to use the alpine image you just use `vaultwarden/server:alpine` instead of `vaultwarden/server:latest`. in order to use the flag you just add `--security-opt seccomp=unconfined` to your docker run command.
OVERLORD commented 2025-10-09 17:05:14 +03:00
Author
Owner
Copy Link

@bassarf commented on GitHub:

This might be related to this issue: moby/moby#40734

If it is, running the container as privileged or seccomp=unconfined should work as a quick and dirty work-around. More permanent solutions are discussed in the linked issue and the other issues linked there.

Thank you for your reply. Indeed using the flag --security-opt seccomp=unconfined works. The server starts and the client is able to sync.

Maybe a strange thing, but could you both try the Alpine image maybe?

Thank you for your reply... this also works.. even without the seccomp flag above.

@bassarf commented on GitHub: > This might be related to this issue: [moby/moby#40734](https://github.com/moby/moby/issues/40734) > > If it is, running the container as privileged or seccomp=unconfined should work as a quick and dirty work-around. More permanent solutions are discussed in the linked issue and the other issues linked there. Thank you for your reply. Indeed using the flag `--security-opt seccomp=unconfined` works. The server starts and the client is able to sync. > Maybe a strange thing, but could you both try the Alpine image maybe? Thank you for your reply... this also works.. even without the `seccomp` flag above.
OVERLORD commented 2025-10-09 17:05:14 +03:00
Author
Owner
Copy Link

@BlackDex commented on GitHub:

Strange, that part of the code is linked to netbsd. Not sure from the top of my head if that is the default Linux for Rust, but that would be strange.

@BlackDex commented on GitHub: Strange, that part of the code is linked to netbsd. Not sure from the top of my head if that is the _default_ Linux for Rust, but that would be strange.
OVERLORD commented 2025-10-09 17:05:15 +03:00
Author
Owner
Copy Link

@moduraziel commented on GitHub:

Im still learning my way around Docker/Portainer...how do I add this flag to my container? Is it just an ENV variable? And how do I access the Alpine image?

@moduraziel commented on GitHub: Im still learning my way around Docker/Portainer...how do I add this flag to my container? Is it just an ENV variable? And how do I access the Alpine image?
OVERLORD commented 2025-10-09 17:05:16 +03:00
Author
Owner
Copy Link

@moduraziel commented on GitHub:

I am running Buster instead of Bullseye due to another app's requirements. Could that be an explanation for these issues?

@moduraziel commented on GitHub: I am running Buster instead of Bullseye due to another app's requirements. Could that be an explanation for these issues?
OVERLORD commented 2025-10-09 17:05:16 +03:00
Author
Owner
Copy Link

@BlackDex commented on GitHub:

From what i understand is that since buster is using an older kernel than bullseye, it doesn't support some system-calls out-of-the box. And that is why you need to use --security-opt seccomp=unconfined to allow these calls to work.

@BlackDex commented on GitHub: From what i understand is that since buster is using an older kernel than bullseye, it doesn't support some system-calls out-of-the box. And that is why you need to use `--security-opt seccomp=unconfined` to allow these calls to work.
OVERLORD commented 2025-10-09 17:05:17 +03:00
Author
Owner
Copy Link

@oven8Mitts commented on GitHub:

Sadly, the Alpine image did not fix the issue on my end, although unconfining seccomp did resolve the issue for me.

@oven8Mitts commented on GitHub: Sadly, the Alpine image did not fix the issue on my end, although unconfining seccomp did resolve the issue for me.
OVERLORD commented 2025-10-09 17:05:18 +03:00
Author
Owner
Copy Link

@moduraziel commented on GitHub:

Thanks for the quick reply. Is it possible to use the seccomp flag through portainer or do I need to run the container through CLI to add the command? I was able to enable Privileged Mode in the GUI for the container, which seemed to work, I'm just curious how you would use that flag. Alpine appears to be working.

Also, from a security perspective, which would be the better choice: Alpine, run flag, or privileged mode?

@moduraziel commented on GitHub: Thanks for the quick reply. Is it possible to use the seccomp flag through portainer or do I need to run the container through CLI to add the command? I was able to enable Privileged Mode in the GUI for the container, which seemed to work, I'm just curious how you would use that flag. Alpine appears to be working. Also, from a security perspective, which would be the better choice: Alpine, run flag, or privileged mode?
OVERLORD commented 2025-10-09 17:05:18 +03:00
Author
Owner
Copy Link

@BlackDex commented on GitHub:

It could be that the docker host has an outdated OS in the sens that it doesn't understand the correct calls. This seems to be a docker<>kernel issue and would probably cause all docker images which are using a newer OS based image and does the same time call break those images. Now I'm not sure we can really solve that.

The reason it is breaking with the newer version is because the Vaultwarden images are using an updated base image since this release compared to the previous one.

reverting back to an older release of the base images isn't really something i would want to do, since those images are using older library versions.

@BlackDex commented on GitHub: It could be that the docker host has an outdated OS in the sens that it doesn't understand the correct calls. This seems to be a docker<>kernel issue and would probably cause all docker images which are using a newer OS based image and does the same time call break those images. Now I'm not sure we can really solve that. The reason it is breaking with the newer version is because the Vaultwarden images are using an updated base image since this release compared to the previous one. reverting back to an older release of the base images isn't really something i would want to do, since those images are using older library versions.
OVERLORD commented 2025-10-09 17:05:19 +03:00
Author
Owner
Copy Link

@moduraziel commented on GitHub:

Ah that makes a lot of sense, then. And that would explain why I got it working a few days ago but not more recently, until I added that flag

@moduraziel commented on GitHub: Ah that makes a lot of sense, then. And that would explain why I got it working a few days ago but not more recently, until I added that flag
OVERLORD commented 2025-10-09 17:05:19 +03:00
Author
Owner
Copy Link

@bassarf commented on GitHub:

It looks like this is a "buster only" problem, since everyone with this issue is running buster (as far as I can see it).
Thus this seems like a "backwards compatibility" issue and I guess won't be fixed (if I understood BlackDex's comment correctly).
So I guess this issue can be closed?!

Maybe a note in the wiki, readme.md and/or release notes, that one might have problems when running buster would be good.
The pihole project had a similar issue with seccomp. Their solution was (as far as I can tell) to not support buster anymore:
https://github.com/pi-hole/docker-pi-hole/releases/tag/2022.04.2

@bassarf commented on GitHub: It looks like this is a "buster only" problem, since everyone with this issue is running buster (as far as I can see it). Thus this seems like a "backwards compatibility" issue and I guess won't be fixed (if I understood BlackDex's comment correctly). So I guess this issue can be closed?! Maybe a note in the wiki, readme.md and/or release notes, that one might have problems when running buster would be good. The pihole project had a similar issue with seccomp. Their solution was (as far as I can tell) to not support buster anymore: https://github.com/pi-hole/docker-pi-hole/releases/tag/2022.04.2
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
better for forum
bug
bug
bug
documentation
duplicate
enhancement
future Vault
good first issue
help wanted
low priority
notes
pull-request
Mirrored from GitHub Pull Request
 question
SSO
Third party
troubleshooting
troubleshooting
wontfix
No Label bug troubleshooting
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#1136
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?