Docker anonymous volumes created

[valankar]

I noticed using the ghcr.io/processone/eturnal:latest docker image, I seem to get a bunch of anonymous docker volumes created.

docker volume ls                                                                                                                                                                                                                                             DRIVER    VOLUME NAME
local     33eb479e9fe77f7e4cb7ce2f0cd2522e845b2c16da54bf712af53ccd02dcbd1d
local     d504df0e6384419840037a434ecb772d1af789e1aaa6031d0566f4f98fdcea5f

root@debian:/var/lib/docker/volumes/33eb479e9fe77f7e4cb7ce2f0cd2522e845b2c16da54bf712af53ccd02dcbd1d/_data/bin# ls -la
total 132
drwxr-xr-x  4 9000 9000  4096 Apr 21 08:28 .
drwxr-xr-x 11 9000 9000  4096 Apr 21 08:28 ..
-rwxr-xr-x  1 9000 9000 36708 Sep 28  2023 eturnal
-rwxr-xr-x  1 9000 9000 36708 Sep 28  2023 eturnal-1.12.0
-rwxr-xr-x  1 9000 9000  4240 Sep 28  2023 eturnalctl

root@debian:/var/lib/docker/volumes/d504df0e6384419840037a434ecb772d1af789e1aaa6031d0566f4f98fdcea5f/_data/bin# ls -la
total 132
drwxr-xr-x  4 9000 9000  4096 Apr 13 17:36 .
drwxr-xr-x 11 9000 9000  4096 Apr 13 17:36 ..
-rwxr-xr-x  1 9000 9000 36708 Sep 28  2023 eturnal
-rwxr-xr-x  1 9000 9000 36708 Sep 28  2023 eturnal-1.12.0
-rwxr-xr-x  1 9000 9000  4240 Sep 28  2023 eturnalctl
...

Any way to prevent these stray volumes being created?

[sando38]

This/these are created, due to the VOLUME definition in the Dockerfile:

eturnal/Dockerfile

Line 277 in 6e0aca8

VOLUME ["/$HOME"]

You may try to create "real" Docker volume with the container path: /opt/eturnal. Effectively this volume is used as a runtime directory and can savely be removed, if the container is stopped.

Starting the container like docker run --rm ghcr.io/processone/eturnal:1.12.0 should also have the same effect due to the --rm flag. Can you try if this is the case? Thanks 👍

[valankar]

I'm using docker compose and for some reason I just keep getting more and more of the stray volumes. Not sure when a new one appears, perhaps after a reboot. Anyhow I tried mounting a volume on /opt/eturnal but the container doesn't start and gives errors:

$ docker logs eturnal
/usr/local/bin/eturnalctl: exec: line 9: /opt/eturnal/bin/eturnalctl: not found
/usr/local/bin/eturnalctl: exec: line 9: /opt/eturnal/bin/eturnalctl: not found
/usr/local/bin/eturnalctl: exec: line 9: /opt/eturnal/bin/eturnalctl: not found
/usr/local/bin/eturnalctl: exec: line 9: /opt/eturnal/bin/eturnalctl: not found
/usr/local/bin/eturnalctl: exec: line 9: /opt/eturnal/bin/eturnalctl: not found
/usr/local/bin/eturnalctl: exec: line 9: /opt/eturnal/bin/eturnalctl: not found
/usr/local/bin/eturnalctl: exec: line 9: /opt/eturnal/bin/eturnalctl: not found
/usr/local/bin/eturnalctl: exec: line 9: /opt/eturnal/bin/eturnalctl: not found

My compose file looks like:

services:
  eturnal:
    image: ghcr.io/processone/eturnal:latest
    container_name: eturnal
    restart: unless-stopped
    network_mode: host
    user: 9000:9000
    read_only: true
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    security_opt:
      - no-new-privileges:true
    environment:
      - STUN_SERVICE=false
    volumes:
      - ./eturnal/eturnal.yml:/etc/eturnal.yml:ro
      - ./eturnal/opt:/opt/eturnal

And I chowned the directory:

$ ls -ld eturnal/opt
drwxr-xr-x 3 9000 9000 4096 Apr 24 03:52 eturnal/opt/

[sando38]

Actually, now when I think about it again, I think it is not possible to avoid the anonymous volume, also not with the trick proposed.

We use the VOLUME to allow read_only: true. The two actual destinations, where eturnal writes into, are /opt/eturnal/log and /opt/eturnal/run.

Also relates to #5