Docker anonymous volumes created about eturnal HOT 3 CLOSED

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

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 👍

from eturnal.

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/

from eturnal.

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

from eturnal.