Docker container v1.25.1 persistent check with volumes fails to start

[aclare92]

Subject of the issue

On starting of the latest (1.25.1) version, it will error stating there is no .env and no persistent storage although configured and working in 1.25.0

Deployment environment

• vaultwarden version: 1.25.1

• Install method: Docker

• Clients used: Application doesn't start at all so presume all clients

• Reverse proxy and version: N/A

• MySQL/MariaDB or PostgreSQL version: N/A

• Other relevant details:

Steps to reproduce

Run the below docker compose; (I have every variable populated but removed for this issue raise)

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    ports:
      - 50003:80
    networks:
      - proxy
    volumes:
      - vaultwarden_data:/data
    environment:
      - ADMIN_TOKEN=
      - WEBSOCKET_ENABLED=true
      - SMTP_HOST=
      - SMTP_FROM=
      - SMTP_FROM_NAME=VaultWarden
      - SMTP_SECURITY=starttls
      - SMTP_PORT=587
      - SMTP_USERNAME=
      - SMTP_PASSWORD=
      - SMTP_TIMEOUT=30
      - SMTP_AUTH_MECHANISM="Plain"
      - LOGIN_RATELIMIT_MAX_BURST=10
      - LOGIN_RATELIMIT_SECONDS=60
      - DOMAIN=
      - INVITATION_ORG_NAME=
      - INVITATIONS_ALLOWED=true
      - SIGNUPS_ALLOWED=false
      - SIGNUPS_DOMAINS_WHITELIST=
      - SIGNUPS_VERIFY=true
      - SIGNUPS_VERIFY_RESEND_TIME=3600
      - SIGNUPS_VERIFY_RESEND_LIMIT=6
      - EMERGENCY_ACCESS_ALLOWED=true
      - SENDS_ALLOWED=true
      - WEB_VAULT_ENABLED=true

Expected behaviour

To launch the application and be accessible via it's port or the remapped port if provided i.e. 50003:80 in this case

Actual behaviour

Application does not start and reviewing the logs, the below is returned;

[INFO] No .env file found.
[2022-07-17 04:21:50.752][vaultwarden][ERROR] No persistent volume!
########################################################################################
# It looks like you did not configure a persistent volume!                             #
# This will result in permanent data loss when the container is removed or updated!    #
# If you really want to use volatile storage set `I_REALLY_WANT_VOLATILE_STORAGE=true` #
########################################################################################

Troubleshooting data

[shadoskill]

Yeah I am experiencing the same issue.

[BlackDex]

Which version of docker/docker-compose are you using?
And is the volume a docker volume, or a directory on the host?

[shadoskill]

Docker: 20.10.17
Unlike the OP I did not use compose, I just ran commands manually.
docker volume create vaultwarden_data
docker run -d --name vaultwarden -v vaultwarden_data:/data/ -p 20000:80 vaultwarden/server:latest

docker volume inspect vaultwarden_data
[ { "CreatedAt": "2022-07-17T07:44:17-05:00", "Driver": "local", "Labels": null, "Mountpoint": "/var/lib/docker/volumes/vaultwarden_data/_data", "Name": "vaultwarden_data", "Options": {}, "Scope": "local" } ]

And then I see the same error in my logs.

[BlackDex]

Looks like this happens when using a volume and not a bind mount from the host.
For now i suggest to add I_REALLY_WANT_VOLATILE_STORAGE=true to the environment config.
That should at least make the latest version work without issues.

[BlackDex]

I'm looking into a way to still being able to detect this in a different way.
I have to do some checking but maybe there is an option.

[teward]

NOTE: This is a quick workaround to solve this, and it'll be recognized as persistent storage by the container. It maps 'persistent data' onto your disk. Which is, in fact, the same thing that the main Bitwarden docker instances want you to do for the same reasons.

Create a local directory for your vaultwarden data in the same directory as your docker-compose file. Then map it in volumes with ./data:/data or similar. This is a workaround that will do a bind-mount. The problem with non-bind-mount storage is that Docker Compose will delete it when told to in a proper docker compose down call that includes destroying the volumes. Hence why it's not 'persistent' without a bind mount or external storage mechanisms where it mounts external storage mechanisms in.

What you've done is created an ephemeral volume in Docker's storage that can be deleted by Docker with the right deletion arguments to docker compose down. Using a local directory as a bind-mount inside the Docker container means that Docker can delete the volume, but not the underlying data.

So your volumes should look like this under the container:

services:
  vaultwarden:
    ...
    volumes:
      - './vaultwarden_data:/data
    ...

... where vaultwarden_data is a directory in your local dir where you have your docker compose file.

(This plagued me on a few containers before, so i've learned how Docker talks and bind-mounts to fix this issue)

[BlackDex]

While that would indeed solve it, it would cause there current data to be lost/stuck in the volume and not on the bind mounted directory.

I'm in the progress of detecting an un-named volume to allow docker/podman volumes unless someone forgot to bind-mount or create a volume.

[BlackDex]

If you can test the current testing release that would be great. That should have fixed the issue.

[oscar-b]

@BlackDex Tested with Version 1.25.1-331f6c08 and all seems fine now (without I_REALLY_WANT_VOLATILE_STORAGE)! 👍🏻

[abcde57219]

I am still having this same issue using the testing container. The issue started for me after an update in mid to late July. Any other thoughts on things I should try to fix?

[BlackDex]

I am still having this same issue using the testing container. The issue started for me after an update in mid to late July. Any other thoughts on things I should try to fix?

Maybe the same as this #2656

[abcde57219]

I was able to get it working, but think I had to do more than #2656. I had to do three things:

1. I copied my existing persistent folder called bitwarden to make a new folder called vaultwarden;
2. I changed the filenames of all persistent files that had bitwarden in them to vaultwarden; and
3. I changed the volume in the docker compose from - /bitwarden:/bitwarden to - /vaultwarden:/data

I am not sure if numbers 1 and 3 were in fact addressing issue #2656.

[BlackDex]

There are no checks done on the naming, you could have even named it 1password and it wouldn't have mattered.
It really only checks if the mounted directory consists of a string of alphanumerical characters with the exact amount of 64.
Both bitwarden and vaultwarden do not match that criteria at all.

It is strange, but good that you were able to solve it.