ttionya / vaultwarden-backup

Backup vaultwarden (formerly known as bitwarden_rs) SQLite3/PostgreSQL/MySQL/MariaDB database by rclone. (Docker)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Unable to start Vaultwarden-backup Docker container

Fiestaman opened this issue · comments

I was able to run the configuration command and configure the remote for rclone successfully. Configuration completes and exits with no issue. Command used to configure rclone:
docker run --rm -it \ --mount type=volume,source=vaultwarden-rclone-data,target=/config/ \ ttionya/vaultwarden-backup:latest \ rclone config

However, when I use the command to run the container itself, it fails with the following error:

docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "/app/entrypoint.sh": stat /app/entrypoint.sh: no such file or directory: unknown.

Command used to run container after configuration(env-file set to .env file path):
docker run -d --restart=always --name vaultwarden_backup --volumes-from=vaultwarden --mount type=volume,source=vaultwarden-rclone-data,target=/config/ --env-file="/path/to/.env" ttionya/vaultwarden-backup:latest

When I check the app directory in the container created under Files, I see an "entrypoint.sh" file present.

I was able to track down my issue. At one point, I had switched the location of my Vaultwarden data from a Docker volume to a host directory, but I still had that volume mounted to /app. This was causing the start of the Docker container to fail while trying to access the scripts. I could see the scripts in the Files section of the container in Docker, but there must have been some sort of routing issue when trying to start. I deleted my vaultwarden container then created a new one without mapping this volume to /app and everything started up after that.

I also ran into an issue with environment variables not loading correctly that I was able to resolve by getting rid of the --env-file and directly bind mounting the .env file to /.env. I saw in your readme that you say to directly mount the .env, and things worked as they should once I switched to doing this.