Database is locked stack trace from libcore

[Lilja]

Subject of the issue

thread 'main' panicked at 'Failed to turn on WAL: DatabaseError(__Unknown, "database is locked")'

The container user is able to write to /data as I've tried to add command: touch /data/hello.

Your environment

Image version 1.13.1

Steps to reproduce

  bitwarden:
    image: "bitwardenrs/server:1.13.1"
    container_name: "bitwarden"
    volumes:
      - '/mnt/Personal/password/bitwarden-data:/data'
    ports:
      - 1337:80
    environment:
         - RUST_BACKTRACE=1
    env_file:
      - secrets/file-permissions.env

$ cat secrets/file-permissions.env
PUID=1000
PGID=1000

Relevant logs

lilja@devnode:~/homelab$ docker-compose up bitwarden
Recreating bitwarden ...
Recreating bitwarden ... done
Attaching to bitwarden
bitwarden               | /--------------------------------------------------------------------\
bitwarden               | |                       Starting Bitwarden_RS                        |
bitwarden               | |                           Version 1.13.1                           |
bitwarden               | |--------------------------------------------------------------------|
bitwarden               | | This is an *unofficial* Bitwarden implementation, DO NOT use the   |
bitwarden               | | official channels to report bugs/features, regardless of client.   |
bitwarden               | | Report URL: https://github.com/dani-garcia/bitwarden_rs/issues/new |
bitwarden               | \--------------------------------------------------------------------/
bitwarden               |
bitwarden               | thread 'main' panicked at 'Failed to turn on WAL: DatabaseError(__Unknown, "database is locked")', src/libcore/result.rs:1188:5
bitwarden               | stack backtrace:
bitwarden               |    0: backtrace::backtrace::libunwind::trace
bitwarden               |              at ./cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
bitwarden               |    1: backtrace::backtrace::trace_unsynchronized
bitwarden               |              at ./cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
bitwarden               |    2: std::sys_common::backtrace::_print_fmt
bitwarden               |              at src/libstd/sys_common/backtrace.rs:84
bitwarden               |    3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
bitwarden               |              at src/libstd/sys_common/backtrace.rs:61
bitwarden               |    4: core::fmt::write
bitwarden               |              at src/libcore/fmt/mod.rs:1025
bitwarden               |    5: std::io::Write::write_fmt
bitwarden               |              at src/libstd/io/mod.rs:1426
bitwarden               |    6: std::sys_common::backtrace::_print
bitwarden               |              at src/libstd/sys_common/backtrace.rs:65
bitwarden               |    7: std::sys_common::backtrace::print
bitwarden               |              at src/libstd/sys_common/backtrace.rs:50
bitwarden               |    8: std::panicking::default_hook::{{closure}}
bitwarden               |              at src/libstd/panicking.rs:193
bitwarden               |    9: std::panicking::default_hook
bitwarden               |              at src/libstd/panicking.rs:210
bitwarden               |   10: std::panicking::rust_panic_with_hook
bitwarden               |              at src/libstd/panicking.rs:471
bitwarden               |   11: rust_begin_unwind
bitwarden               |              at src/libstd/panicking.rs:375
bitwarden               |   12: core::panicking::panic_fmt
bitwarden               |              at src/libcore/panicking.rs:84
bitwarden               |   13: core::result::unwrap_failed
bitwarden               |              at src/libcore/result.rs:1188
bitwarden               |   14: bitwarden_rs::main
bitwarden               |   15: std::rt::lang_start::{{closure}}
bitwarden               |   16: std::rt::lang_start_internal::{{closure}}
bitwarden               |              at src/libstd/rt.rs:52
bitwarden               |   17: std::panicking::try::do_call
bitwarden               |              at src/libstd/panicking.rs:292
bitwarden               |   18: __rust_maybe_catch_panic
bitwarden               |              at src/libpanic_unwind/lib.rs:78
bitwarden               |   19: std::panicking::try
bitwarden               |              at src/libstd/panicking.rs:270
bitwarden               |   20: std::panic::catch_unwind
bitwarden               |              at src/libstd/panic.rs:394
bitwarden               |   21: std::rt::lang_start_internal
bitwarden               |              at src/libstd/rt.rs:51
bitwarden               |   22: main
bitwarden               |   23: __libc_start_main
bitwarden               |   24: _start
bitwarden               | note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
bitwarden exited with code 101

Full stacktrace:

Going to remove bitwarden
Removing bitwarden ... done
Creating bitwarden ...
Creating bitwarden ... done
Attaching to bitwarden
bitwarden               | /--------------------------------------------------------------------\
bitwarden               | |                       Starting Bitwarden_RS                        |
bitwarden               | |                           Version 1.13.1                           |
bitwarden               | |--------------------------------------------------------------------|
bitwarden               | | This is an *unofficial* Bitwarden implementation, DO NOT use the   |
bitwarden               | | official channels to report bugs/features, regardless of client.   |
bitwarden               | | Report URL: https://github.com/dani-garcia/bitwarden_rs/issues/new |
bitwarden               | \--------------------------------------------------------------------/
bitwarden               |
bitwarden               | thread 'main' panicked at 'Failed to turn on WAL: DatabaseError(__Unknown, "database is locked")', src/libcore/result.rs:1188:5
bitwarden               | stack backtrace:
bitwarden               |    0:     0x55c5b2b4fb44 - backtrace::backtrace::libunwind::trace::h0a48c85c8012426b
bitwarden               |                                at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
bitwarden               |    1:     0x55c5b2b4fb44 - backtrace::backtrace::trace_unsynchronized::hd59d821c5709c879
bitwarden               |                                at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
bitwarden               |    2:     0x55c5b2b4fb44 - std::sys_common::backtrace::_print_fmt::h1aa050417bb0b607
bitwarden               |                                at src/libstd/sys_common/backtrace.rs:84
bitwarden               |    3:     0x55c5b2b4fb44 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h068618ade673b259
bitwarden               |                                at src/libstd/sys_common/backtrace.rs:61
bitwarden               |    4:     0x55c5b2b77e0c - core::fmt::write::h72d2c3a2a8405f91
bitwarden               |                                at src/libcore/fmt/mod.rs:1025
bitwarden               |    5:     0x55c5b2b488a7 - std::io::Write::write_fmt::h36b1a7b93b325264
bitwarden               |                                at src/libstd/io/mod.rs:1426
bitwarden               |    6:     0x55c5b2b51cfe - std::sys_common::backtrace::_print::h40b9c256f1edfa08
bitwarden               |                                at src/libstd/sys_common/backtrace.rs:65
bitwarden               |    7:     0x55c5b2b51cfe - std::sys_common::backtrace::print::h0f6ce4b3cbaba788
bitwarden               |                                at src/libstd/sys_common/backtrace.rs:50
bitwarden               |    8:     0x55c5b2b51cfe - std::panicking::default_hook::{{closure}}::h2e0a4a0d4aa5cb77
bitwarden               |                                at src/libstd/panicking.rs:193
bitwarden               |    9:     0x55c5b2b519f1 - std::panicking::default_hook::ha8ece3680c7da126
bitwarden               |                                at src/libstd/panicking.rs:210
bitwarden               |   10:     0x55c5b2b523db - std::panicking::rust_panic_with_hook::h748222843c9136a2
bitwarden               |                                at src/libstd/panicking.rs:471
bitwarden               |   11:     0x55c5b2b51f8e - rust_begin_unwind
bitwarden               |                                at src/libstd/panicking.rs:375
bitwarden               |   12:     0x55c5b2b743ae - core::panicking::panic_fmt::h28daaedf5bd7eef6
bitwarden               |                                at src/libcore/panicking.rs:84
bitwarden               |   13:     0x55c5b2b744a7 - core::result::unwrap_failed::hc936aea0e5f8bdac
bitwarden               |                                at src/libcore/result.rs:1188
bitwarden               |   14:     0x55c5b22a8ef9 - bitwarden_rs::main::hd7d0a81ca1233fb7
bitwarden               |   15:     0x55c5b253aeb3 - std::rt::lang_start::{{closure}}::h4c539ce4968cd2bc
bitwarden               |   16:     0x55c5b2b51e23 - std::rt::lang_start_internal::{{closure}}::ha966a90a2223d318
bitwarden               |                                at src/libstd/rt.rs:52
bitwarden               |   17:     0x55c5b2b51e23 - std::panicking::try::do_call::h7048802f1f0056de
bitwarden               |                                at src/libstd/panicking.rs:292
bitwarden               |   18:     0x55c5b2b5bf8a - __rust_maybe_catch_panic
bitwarden               |                                at src/libpanic_unwind/lib.rs:78
bitwarden               |   19:     0x55c5b2b52930 - std::panicking::try::h3d7ba80ee84a3ede
bitwarden               |                                at src/libstd/panicking.rs:270
bitwarden               |   20:     0x55c5b2b52930 - std::panic::catch_unwind::h2f15a5533e64a496
bitwarden               |                                at src/libstd/panic.rs:394
bitwarden               |   21:     0x55c5b2b52930 - std::rt::lang_start_internal::h0e133c31a2e415aa
bitwarden               |                                at src/libstd/rt.rs:51
bitwarden               |   22:     0x55c5b22ab0b2 - main
bitwarden               |   23:     0x7f16d961b09b - __libc_start_main
bitwarden               |   24:     0x55c5b21d956a - _start
bitwarden               |   25:                0x0 - <unknown>

[Lilja]

The mount is an SMB share from my NAS. I removed it so it places the data container on the local file system and it works. Perhaps it's best that way? And then perform backup with sqlite export tool to it instead?

[yggdrasil-tynor]

@Lilja You need to disable WAL. You can do it by setting an environment variable. See https://github.com/dani-garcia/bitwarden_rs/wiki/Running-without-WAL-enabled

[dani-garcia]

Closed due to inactivity.

[josuemotte]

Just had the same issue on SWARM cluster using freenas and SMB ;

I fixed it by using the nolock option and mounting the share.

Example :

cat/usr/lib/systemd/system/mnt-smb.mount
[Unit]
  Description=SMB mount script
  Requires=network.target
  After=network.service

[Mount]
  What=//amazingNAS.local.io/smb
  Where=/mnt/smb
  Options=credentials=/tmp/.smbcredentials,nolock,soft,rsize=32768,wsize=32768
  Type=cifs

[Install]
  WantedBy=multi-user.target

Some people face it here for another tool : Sonarr/Sonarr#1886

However I never had this issue while using CEPH as storage... Might be worth to use it instead of NFS,CIFS and GlusterFS

[BloodyIron]

I had to use "nobrl" flag instead of "nolock" when using the vaultwarden docker image in kubernetes, as "nolock" was being rejected for the CSI Driver for SMB, but it seems to accept "nobrl" instead. Posting for future humans.

[BlackDex]

The nobrl is also the correct flag to use for CIFS/SMB to support this.
Though i still suggest to use PostgreSQL or MariaDB/MySQL in these cases.

[BloodyIron]

The nobrl is also the correct flag to use for CIFS/SMB to support this. Though i still suggest to use PostgreSQL or MariaDB/MySQL in these cases.

Why? What is the tangible benefit to spin up another database when this is a workable solution?

Also, CIFS is a misnomer. It was a variant name for SMBv1.0 made by Microsoft that never took off, and hasn't been relevant for over 20 years. SMBv2.0/onwards never was and never will be CIFS, it's been SMB the whole time. (I know you're not the only one continuing to use CIFS as a term, but yeah, it's an irrelevant and inaccurate term).