Command not found: sqlite3 #1392

New Issue

OVERLORD · 2025-10-09T17:13:44+03:00

OVERLORD commented

2025-10-09 17:13:44 +03:00

Originally created by @alexpovel on GitHub.

Subject of the issue

The docs for backing up Vaultwarden still mention SQLite and its corresponding sqlite3 binary. Back when I first started using Bitwarden_RS, I had written a backup script around that (requires rsync):

Click to expand

#!/bin/sh

# Custom script to backup a Bitwarden installation.
# This requires getting a database dump and rsyncing that dump and
# the attachment directory over to a mounted backup destination.
# The script is agnostic to what the backup destination actually is.

# See also:
# https://github.com/dani-garcia/bitwarden_rs/wiki/Backing-up-your-vault

# Options for this script:
# x: Show debugging
# e: Exit immediately if a command exits with a non-zero status.
# u: Treat unset variables as an error when substituting.
set -eux

echo "Running $(basename "$0") as $(id)."

# Dot is important as an anchor for rsync and its --relative option.
# Trailing slash is also required for rsync to work correctly.
TMP_DATABASE_DUMP_DIR=/backup/./db/
TMP_DATABASE_DUMP_FILE=bitwarden.sql.bak

# For rsync, the trailing slash is important
BACKUP_DIR=/mnt/backup/

ATTACHMENTS_DIR=${DATA_FOLDER}/./attachments/

cleanup() {
    # Collect cleanup operations here; guarantees these are run when trapped
    rm -r "$TMP_DATABASE_DUMP_DIR"
}

# On script EXIT, run command
trap "cleanup" EXIT

mkdir -p "$TMP_DATABASE_DUMP_DIR"

echo "Getting database dump"

sqlite3 "$DATA_FOLDER"/db.sqlite3 ".backup '${TMP_DATABASE_DUMP_DIR}${TMP_DATABASE_DUMP_FILE}'"

echo "Got database dump, wrote to ${TMP_DATABASE_DUMP_DIR}${TMP_DATABASE_DUMP_FILE}"

echo "Starting rsync for all data"
# For rsync options, see its help and also
# https://gist.github.com/KartikTalwar/4393116
# The destination is backed up and versioned *in itself*. We therefore only copy stuff
# over in the simple-most way, without dates in filenames and such.
# Multiple inputs paths are possible; all but the last are sources, last is destination.
rsync \
    --acls \
    --archive \
    --delete \
    --human-readable \
    --info=NAME1,DEL1,SKIP1,STATS3 \
    --relative \
    --xattrs \
    "$ATTACHMENTS_DIR" \
    "$TMP_DATABASE_DUMP_DIR" \
    "$BACKUP_DIR"

echo "Finished rsync, exiting"

It has been working just fine but recently broke. I feel like I missed something because there isn't an open issue on this yet, but the docs linked above seem reasonably up to date (mention sends directory), so I'm hoping the sqlite3 part is still relevant.

I have looked in different locations for help but wasn't succesful:

https://github.com/dani-garcia/vaultwarden/releases/tag/1.17.0 is a minor release with lots of DB changes, but was long ago and doesn't make any mention of moving away from sqlite3
#1492 is about MySQL/MariaDB
#1646 is an update from 1.16 to 1.21 with lots of DB migration stuff, but I updated from 1.20 to 1.21 and see none of that in my logs
#1647 mentions "vaultwarden one has no sqlite executable", which I can confirm but doesn't help

Deployment environment

vaultwarden version:

 $ docker pull vaultwarden/server && docker inspect vaultwarden/server
 Using default tag: latest
 latest: Pulling from vaultwarden/server
 Digest: sha256:9303a3efb19f002631c7825b8db1eceb4a97bac716d391ac4b434f9aef344958
 Status: Image is up to date for vaultwarden/server:latest
 docker.io/vaultwarden/server:latest
 [
     {
         "Id": "sha256:ca7d174aef769b69c15e1d9d90900f40cafd927cfdd77397c5d4210a2b79c211",
         "RepoTags": [
             "vaultwarden/server:latest"
         ],
         "RepoDigests": [
             "vaultwarden/server@sha256:9303a3efb19f002631c7825b8db1eceb4a97bac716d391ac4b434f9aef344958"
         ],
         "Parent": "",
         "Comment": "",
         "Created": "2021-04-30T15:12:00.890378129Z",
         "Container": "",
         "ContainerConfig": {
             "Hostname": "",
             "Domainname": "",
             "User": "",
             "AttachStdin": false,
             "AttachStdout": false,
             "AttachStderr": false,
             "Tty": false,
             "OpenStdin": false,
             "StdinOnce": false,
             "Env": null,
             "Cmd": null,
             "Image": "",
             "Volumes": null,
             "WorkingDir": "",
             "Entrypoint": null,
             "OnBuild": null,
             "Labels": null
         },
         "DockerVersion": "",
         "Author": "",
         "Config": {
             "Hostname": "",
             "Domainname": "",
             "User": "",
             "AttachStdin": false,
             "AttachStdout": false,
             "AttachStderr": false,
             "ExposedPorts": {
                 "3012/tcp": {},
                 "80/tcp": {}
             },
             "Tty": false,
             "OpenStdin": false,
             "StdinOnce": false,
             "Env": [
                 "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
                 "ROCKET_ENV=staging",
                 "ROCKET_PORT=80",
                 "ROCKET_WORKERS=10"
             ],
             "Cmd": [
                 "/start.sh"
             ],
             "Healthcheck": {
                 "Test": [
                     "CMD",
                     "/healthcheck.sh"
                 ],
                 "Interval": 60000000000,
                 "Timeout": 10000000000
             },
             "Image": "",
             "Volumes": {
                 "/data": {}
             },
             "WorkingDir": "/",
             "Entrypoint": [
                 "/usr/bin/dumb-init",
                 "--"
             ],
             "OnBuild": null,
             "Labels": {
                 "org.opencontainers.image.created": "2021-04-30T14:49:52+00:00",
                 "org.opencontainers.image.documentation": "https://github.com/dani-garcia/vaultwarden/wiki",
                 "org.opencontainers.image.licenses": "GPL-3.0-only",
                 "org.opencontainers.image.revision": "1e5306b8203a7ebe24047910e6c690c18c6d827a",
                 "org.opencontainers.image.source": "https://github.com/dani-garcia/vaultwarden",
                 "org.opencontainers.image.url": "https://hub.docker.com/r/vaultwarden/server",
                 "org.opencontainers.image.version": "1.21.0"
             }
         },
         "Architecture": "amd64",
         "Os": "linux",
         "Size": 178520878,
         "VirtualSize": 178520878,
         "GraphDriver": {
             "Data": {
                 "LowerDir": "/var/lib/docker/overlay2/f679b79840ef74c86863b7d979fbe1d8c82924e9bee6a2138cc841a9f61eb09c/diff:/var/lib/docker/overlay2/5a5b76c46e2fbc7132f78c34fa478d3b087b81886a4795312ce365ff1e7cc402/diff:/var/lib/docker/overlay2/a04edbd27432bcfdda8fc3834647e183d8d8da92d1576e661689433659f34c31/diff:/var/lib/docker/overlay2/60beb58637805221040008ca8fe3ad07d89ea3edcc59b39ccdf1fd0a234f4921/diff:/var/lib/docker/overlay2/eb3d200376d6e1c690e253f7649ad761bd3d13d60a0dc5ab1d85ff012c2d3e10/diff:/var/lib/docker/overlay2/76160244325bbfc2a26f784ecd23dfb9dd83a216494ffacee861e7b3638df717/diff:/var/lib/docker/overlay2/6356ca7c6a6df11ea84fbedc18712ed8d5a742d83effb095924b66e6241f9f3e/diff",
                 "MergedDir": "/var/lib/docker/overlay2/6fce2a9254633c9bbcdfaeef0c20de936d9a9ff0794c9f7865d1f2ab369f0e24/merged",
                 "UpperDir": "/var/lib/docker/overlay2/6fce2a9254633c9bbcdfaeef0c20de936d9a9ff0794c9f7865d1f2ab369f0e24/diff",
                 "WorkDir": "/var/lib/docker/overlay2/6fce2a9254633c9bbcdfaeef0c20de936d9a9ff0794c9f7865d1f2ab369f0e24/work"
             },
             "Name": "overlay2"
         },
         "RootFS": {
             "Type": "layers",
             "Layers": [
                 "sha256:7e718b9c0c8c2e6420fe9c4d1d551088e314fe923dce4b2caf75891d82fb227d",
                 "sha256:def104127282fe2861c66c6bdefd58bdfdc09d2d38026e3bb8db6044b040dadd",
                 "sha256:2ab5bbd7df9604b4243d394284025b95fd9d351a530876b2c0552dc0aa38e4f6",
                 "sha256:df9933473761d880d7dedfbaf07450fc2c139017ec2f0212fa904b132b70107c",
                 "sha256:f0ad681d19836cc2514f86f530312d7c14f338b11746b0d408a54a4b52381585",
                 "sha256:62e3cf577e2c8a5b29182de52c1238ee7c122c4324ff32743fe73a624a16a89b",
                 "sha256:b8af4836b9303c3223ff435a5959b4e32daa01ab8a2d4f30d2a27cf5fb284f46",
                 "sha256:8369906ae231db354cb1b9fa742554c16d7538fe782b38fd816899a1de19ceb6"
             ]
         },
         "Metadata": {
             "LastTagTime": "0001-01-01T00:00:00Z"
         }
     }
 ]

Install method: Docker
MySQL/MariaDB or PostgreSQL version: SQLite!

Steps to reproduce

There's no sqlite3 program anymore in the current Docker image (see above for the exact version):

$ docker run --rm -it --entrypoint=sqlite3 vaultwarden/server --version
docker: Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: exec: "sqlite3": executable file not found in $PATH: unknown.

Expected behaviour

sqlite3 to be present so backups succeed as described in the docs.

Its present in 1.20, so one minor version prior (vaultwarden/server isn't available for this one):

$ docker run --rm -it --entrypoint=sqlite3 bitwardenrs/server:1.20.0 --version
3.27.2 2019-02-25 16:06:06 bd49a8271d650fa89e446b42e513b595a717b9212c91dd384aab871fc1d0alt1
$ docker run --rm -it --entrypoint=sqlite3 bitwardenrs/server:1.21.0 --version
docker: Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: exec: "sqlite3": executable file not found in $PATH: unknown.

That tells me the place to look for such a breaking change is the 1.21 changelog, but there's nothing there concerning databases.

Actual behaviour

sqlite3 is not present (apt-get install sqlite3 in a child image fixes this for now).

Originally created by @alexpovel on GitHub.   ### Subject of the issue  The [docs](https://github.com/dani-garcia/vaultwarden/wiki/Backing-up-your-vault#sqlite-database-files) for backing up Vaultwarden still mention SQLite and its corresponding `sqlite3` binary. Back when I first started using Bitwarden_RS, I had written a backup script around that (requires `rsync`): <details> <summary>Click to expand</summary> ```sh #!/bin/sh # Custom script to backup a Bitwarden installation. # This requires getting a database dump and rsyncing that dump and # the attachment directory over to a mounted backup destination. # The script is agnostic to what the backup destination actually is. # See also: # https://github.com/dani-garcia/bitwarden_rs/wiki/Backing-up-your-vault # Options for this script: # x: Show debugging # e: Exit immediately if a command exits with a non-zero status. # u: Treat unset variables as an error when substituting. set -eux echo "Running $(basename "$0") as $(id)." # Dot is important as an anchor for rsync and its --relative option. # Trailing slash is also required for rsync to work correctly. TMP_DATABASE_DUMP_DIR=/backup/./db/ TMP_DATABASE_DUMP_FILE=bitwarden.sql.bak # For rsync, the trailing slash is important BACKUP_DIR=/mnt/backup/ ATTACHMENTS_DIR=${DATA_FOLDER}/./attachments/ cleanup() { # Collect cleanup operations here; guarantees these are run when trapped rm -r "$TMP_DATABASE_DUMP_DIR" } # On script EXIT, run command trap "cleanup" EXIT mkdir -p "$TMP_DATABASE_DUMP_DIR" echo "Getting database dump" sqlite3 "$DATA_FOLDER"/db.sqlite3 ".backup '${TMP_DATABASE_DUMP_DIR}${TMP_DATABASE_DUMP_FILE}'" echo "Got database dump, wrote to ${TMP_DATABASE_DUMP_DIR}${TMP_DATABASE_DUMP_FILE}" echo "Starting rsync for all data" # For rsync options, see its help and also # https://gist.github.com/KartikTalwar/4393116 # The destination is backed up and versioned *in itself*. We therefore only copy stuff # over in the simple-most way, without dates in filenames and such. # Multiple inputs paths are possible; all but the last are sources, last is destination. rsync \ --acls \ --archive \ --delete \ --human-readable \ --info=NAME1,DEL1,SKIP1,STATS3 \ --relative \ --xattrs \ "$ATTACHMENTS_DIR" \ "$TMP_DATABASE_DUMP_DIR" \ "$BACKUP_DIR" echo "Finished rsync, exiting" ``` </details> It has been working just fine but recently broke. I feel like I missed something because there isn't an open issue on this yet, but the docs linked above seem reasonably up to date (mention `sends` directory), so I'm hoping the `sqlite3` part is still relevant. I have looked in different locations for help but wasn't succesful: - https://github.com/dani-garcia/vaultwarden/releases/tag/1.17.0 is a minor release with lots of DB changes, but was long ago and doesn't make any mention of moving away from `sqlite3` - #1492 is about MySQL/MariaDB - #1646 is an update from `1.16` to `1.21` with lots of DB migration stuff, but I updated from `1.20` to `1.21` and see none of that in my logs - #1647 mentions "`vaultwarden one has no sqlite executable`", which I can confirm but doesn't help ### Deployment environment     * vaultwarden version: ```json $ docker pull vaultwarden/server && docker inspect vaultwarden/server Using default tag: latest latest: Pulling from vaultwarden/server Digest: sha256:9303a3efb19f002631c7825b8db1eceb4a97bac716d391ac4b434f9aef344958 Status: Image is up to date for vaultwarden/server:latest docker.io/vaultwarden/server:latest [ { "Id": "sha256:ca7d174aef769b69c15e1d9d90900f40cafd927cfdd77397c5d4210a2b79c211", "RepoTags": [ "vaultwarden/server:latest" ], "RepoDigests": [ "vaultwarden/server@sha256:9303a3efb19f002631c7825b8db1eceb4a97bac716d391ac4b434f9aef344958" ], "Parent": "", "Comment": "", "Created": "2021-04-30T15:12:00.890378129Z", "Container": "", "ContainerConfig": { "Hostname": "", "Domainname": "", "User": "", "AttachStdin": false, "AttachStdout": false, "AttachStderr": false, "Tty": false, "OpenStdin": false, "StdinOnce": false, "Env": null, "Cmd": null, "Image": "", "Volumes": null, "WorkingDir": "", "Entrypoint": null, "OnBuild": null, "Labels": null }, "DockerVersion": "", "Author": "", "Config": { "Hostname": "", "Domainname": "", "User": "", "AttachStdin": false, "AttachStdout": false, "AttachStderr": false, "ExposedPorts": { "3012/tcp": {}, "80/tcp": {} }, "Tty": false, "OpenStdin": false, "StdinOnce": false, "Env": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "ROCKET_ENV=staging", "ROCKET_PORT=80", "ROCKET_WORKERS=10" ], "Cmd": [ "/start.sh" ], "Healthcheck": { "Test": [ "CMD", "/healthcheck.sh" ], "Interval": 60000000000, "Timeout": 10000000000 }, "Image": "", "Volumes": { "/data": {} }, "WorkingDir": "/", "Entrypoint": [ "/usr/bin/dumb-init", "--" ], "OnBuild": null, "Labels": { "org.opencontainers.image.created": "2021-04-30T14:49:52+00:00", "org.opencontainers.image.documentation": "https://github.com/dani-garcia/vaultwarden/wiki", "org.opencontainers.image.licenses": "GPL-3.0-only", "org.opencontainers.image.revision": "1e5306b8203a7ebe24047910e6c690c18c6d827a", "org.opencontainers.image.source": "https://github.com/dani-garcia/vaultwarden", "org.opencontainers.image.url": "https://hub.docker.com/r/vaultwarden/server", "org.opencontainers.image.version": "1.21.0" } }, "Architecture": "amd64", "Os": "linux", "Size": 178520878, "VirtualSize": 178520878, "GraphDriver": { "Data": { "LowerDir": "/var/lib/docker/overlay2/f679b79840ef74c86863b7d979fbe1d8c82924e9bee6a2138cc841a9f61eb09c/diff:/var/lib/docker/overlay2/5a5b76c46e2fbc7132f78c34fa478d3b087b81886a4795312ce365ff1e7cc402/diff:/var/lib/docker/overlay2/a04edbd27432bcfdda8fc3834647e183d8d8da92d1576e661689433659f34c31/diff:/var/lib/docker/overlay2/60beb58637805221040008ca8fe3ad07d89ea3edcc59b39ccdf1fd0a234f4921/diff:/var/lib/docker/overlay2/eb3d200376d6e1c690e253f7649ad761bd3d13d60a0dc5ab1d85ff012c2d3e10/diff:/var/lib/docker/overlay2/76160244325bbfc2a26f784ecd23dfb9dd83a216494ffacee861e7b3638df717/diff:/var/lib/docker/overlay2/6356ca7c6a6df11ea84fbedc18712ed8d5a742d83effb095924b66e6241f9f3e/diff", "MergedDir": "/var/lib/docker/overlay2/6fce2a9254633c9bbcdfaeef0c20de936d9a9ff0794c9f7865d1f2ab369f0e24/merged", "UpperDir": "/var/lib/docker/overlay2/6fce2a9254633c9bbcdfaeef0c20de936d9a9ff0794c9f7865d1f2ab369f0e24/diff", "WorkDir": "/var/lib/docker/overlay2/6fce2a9254633c9bbcdfaeef0c20de936d9a9ff0794c9f7865d1f2ab369f0e24/work" }, "Name": "overlay2" }, "RootFS": { "Type": "layers", "Layers": [ "sha256:7e718b9c0c8c2e6420fe9c4d1d551088e314fe923dce4b2caf75891d82fb227d", "sha256:def104127282fe2861c66c6bdefd58bdfdc09d2d38026e3bb8db6044b040dadd", "sha256:2ab5bbd7df9604b4243d394284025b95fd9d351a530876b2c0552dc0aa38e4f6", "sha256:df9933473761d880d7dedfbaf07450fc2c139017ec2f0212fa904b132b70107c", "sha256:f0ad681d19836cc2514f86f530312d7c14f338b11746b0d408a54a4b52381585", "sha256:62e3cf577e2c8a5b29182de52c1238ee7c122c4324ff32743fe73a624a16a89b", "sha256:b8af4836b9303c3223ff435a5959b4e32daa01ab8a2d4f30d2a27cf5fb284f46", "sha256:8369906ae231db354cb1b9fa742554c16d7538fe782b38fd816899a1de19ceb6" ] }, "Metadata": { "LastTagTime": "0001-01-01T00:00:00Z" } } ] ```  * Install method: Docker * MySQL/MariaDB or PostgreSQL version: SQLite! ### Steps to reproduce  **There's no `sqlite3` program anymore** in the current Docker image (see above for the exact version): ```bash $ docker run --rm -it --entrypoint=sqlite3 vaultwarden/server --version docker: Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: exec: "sqlite3": executable file not found in $PATH: unknown. ``` ### Expected behaviour  `sqlite3` to be present so backups succeed as described in the docs. Its present in `1.20`, so one minor version prior (`vaultwarden/server` isn't available for this one): ```bash $ docker run --rm -it --entrypoint=sqlite3 bitwardenrs/server:1.20.0 --version 3.27.2 2019-02-25 16:06:06 bd49a8271d650fa89e446b42e513b595a717b9212c91dd384aab871fc1d0alt1 $ docker run --rm -it --entrypoint=sqlite3 bitwardenrs/server:1.21.0 --version docker: Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: exec: "sqlite3": executable file not found in $PATH: unknown. ``` That tells me the place to look for such a breaking change is the [1.21 changelog](https://github.com/dani-garcia/vaultwarden/releases/tag/1.21.0), but there's nothing there concerning databases. ### Actual behaviour  `sqlite3` is not present (`apt-get install sqlite3` in a child image fixes this for now).

OVERLORD closed this issue

2025-10-09 17:13:45 +03:00

OVERLORD commented

2025-10-09 17:13:46 +03:00

@alexpovel commented on GitHub:

@fdisamuel excellent, thanks for pointing out the exact commit. I have built multipe services around the idea of backing up from within containers:

each container that is to be backed up gets the following:
- a bind mount into the container at /mnt/backup (using Docker's built-in NFS driver, so the backups go directly to the correct destination)
- a script at /etc/backup.sh; these are tailor-made for each application, like the one in the OP for vaultwarden
- a container label like backup.enabled
the host has a systemd timer and simply gets all containers with the above label, and runs docker exec <id> /etc/backup.sh, where those shell scripts write to /mnt/backup

Anyway... that's why running everything from within the containers is my chosen course of action. After all, these containers already ship with everything required, might as well use them. (Sometimes we need to be in the container anyway, like to enable maintenance mode for Nextcloud) It only sucks for scheduling, so that's done on the host.

Yeah, the docs are mostly meant for the user running the sqlite command from the host side, where the data directory is mounted.

Ah okay, I read that wrong then.

If you still want to run it from inside the container, mounting a shell script into /etc/vaultwarden.sh or /etc/vaultwarden.d/*.sh inside the container would run that script during startup, so you can make sure anything else you need inside the container is installed any time.

Okay thanks! But I take it it's safe to apt-get install sqlite3 in a child image and continue that route? Would be much more Docker-friendly.

@alexpovel commented on GitHub: @fdisamuel excellent, thanks for pointing out the exact commit. I have built multipe services around the idea of backing up from *within* containers: - each container that is to be backed up gets the following: - a bind mount into the container at `/mnt/backup` (using Docker's built-in NFS driver, so the backups go directly to the correct destination) - a script at `/etc/backup.sh`; these are tailor-made for each application, like the one in the OP for vaultwarden - a container label like `backup.enabled` - the host has a `systemd` timer and simply gets all containers with the above label, and runs `docker exec <id> /etc/backup.sh`, where those shell scripts write to `/mnt/backup` Anyway... that's why running everything from within the containers is my chosen course of action. After all, these containers already ship with everything required, might as well use them. (Sometimes we *need* to be in the container anyway, like to enable maintenance mode for Nextcloud) It only sucks for scheduling, so that's done on the host. --- > Yeah, the docs are mostly meant for the user running the sqlite command from the host side, where the data directory is mounted. Ah okay, I read that wrong then. > If you still want to run it from inside the container, mounting a shell script into `/etc/vaultwarden.sh` or `/etc/vaultwarden.d/*.sh` inside the container would run that script during startup, so you can make sure anything else you need inside the container is installed any time. Okay thanks! But I take it it's safe to `apt-get install sqlite3` in a child image and continue that route? Would be much more Docker-friendly.

OVERLORD commented

2025-10-09 17:13:46 +03:00

@fdisamuel commented on GitHub:

Hi @alexpovel!

I think this commit is related to your problem:
95fc88ae5b

Use VACUUM INTO to create a SQLite backup instead of using the external sqlite3 application.

This also removes the dependancy of having the sqlite3 packages installed on the final image unnecessary, and thus removed it.

As you can see, local sqlite3 packages has been removed from the image, as they are not needed anymore for the admin panel database backup function.
My workaround for this, that I run my backup script from the host system which has the necessary sqlite3 packages, not inside the container (I use bind mount from the /data directory to my host local /home/user/bwdata folder so I can reach and backup the db.sqlite3 from the host.)

@fdisamuel commented on GitHub: Hi @alexpovel! I think this commit is related to your problem: https://github.com/dani-garcia/vaultwarden/commit/95fc88ae5bef5f4d1e9a8da4f5de7c955fb75a19 > Use `VACUUM INTO` to create a SQLite backup instead of using the external sqlite3 application. > - This also removes the dependancy of having the sqlite3 packages installed on the final image unnecessary, and thus removed it. As you can see, local sqlite3 packages has been removed from the image, as they are not needed anymore for the admin panel database backup function. My workaround for this, that I run my backup script from the host system which has the necessary sqlite3 packages, not inside the container (I use bind mount from the `/data` directory to my host local `/home/user/bwdata` folder so I can reach and backup the `db.sqlite3` from the host.)

OVERLORD commented

2025-10-09 17:13:47 +03:00

@dani-garcia commented on GitHub:

Yeah, the docs are mostly meant for the user running the sqlite command from the host side, where the data directory is mounted.

If you still want to run it from inside the container, mounting a shell script into /etc/vaultwarden.sh or /etc/vaultwarden.d/*.sh inside the container would run that script during startup, so you can make sure anything else you need inside the container is installed any time.

@dani-garcia commented on GitHub: Yeah, the docs are mostly meant for the user running the sqlite command from the host side, where the data directory is mounted. If you still want to run it from inside the container, mounting a shell script into `/etc/vaultwarden.sh` or `/etc/vaultwarden.d/*.sh` inside the container would run that script during startup, so you can make sure anything else you need inside the container is installed any time.

OVERLORD commented

2025-10-09 17:13:48 +03:00

@andrewlow commented on GitHub:

Maybe the wiki doc should be updated to make it more clear that sqlite3 is NOT in the image, but should be on the host?

https://github.com/dani-garcia/vaultwarden/wiki/Backing-up-your-vault#restoring-backup-data

I personally just added the "missing" sqlite3 command to the container image which let my old script work fine (which did the backup from within the image).

@andrewlow commented on GitHub: Maybe the wiki doc should be updated to make it more clear that sqlite3 is NOT in the image, but should be on the host? https://github.com/dani-garcia/vaultwarden/wiki/Backing-up-your-vault#restoring-backup-data I personally just added the "missing" sqlite3 command to the container image which let my old script work fine (which did the backup from within the image).

OVERLORD commented

2025-10-09 17:13:49 +03:00

@jjlin commented on GitHub:

Docker images are expected to be minimalistic, but for users who aren't familiar with the Docker philosophy, I've updated https://github.com/dani-garcia/vaultwarden/wiki/Backing-up-your-vault#sqlite-database-files.

@jjlin commented on GitHub: Docker images are expected to be minimalistic, but for users who aren't familiar with the Docker philosophy, I've updated https://github.com/dani-garcia/vaultwarden/wiki/Backing-up-your-vault#sqlite-database-files.

OVERLORD commented

2025-10-09 17:13:50 +03:00

@andrewlow commented on GitHub:

💯 agree on minimalistic docker images.

However, the small addition of the sqlite3 command enables that same minimal image to do backups.

Now that said, I trigger the job from outside the container (using cron) - because adding cron to the image would be very much against the docker philosophy.

 docker exec bitwarden sqlite3 /data/db.sqlite3 ".backup '/data/db-backups/backup.sqlite3'"

The doc update looks good and helps people understand the recommended way to do this - I value the time and effort the folks maintaining this project put into, so thank you.

@andrewlow commented on GitHub: 💯 agree on minimalistic docker images. However, the small addition of the sqlite3 command enables that same minimal image to do backups. Now that said, I trigger the job from outside the container (using cron) - because adding cron to the image would be very much against the docker philosophy. ``` docker exec bitwarden sqlite3 /data/db.sqlite3 ".backup '/data/db-backups/backup.sqlite3'" ``` The doc update looks good and helps people understand the recommended way to do this - I value the time and effort the folks maintaining this project put into, so thank you.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#1392