相对路径不适用于 docker-compose.yml 中的命名卷

Question

I need to make a named volume use a relative path to the folder where the docker-compose command is executed.

Here is the volume definition in the docker-compose.yml

volumes:
  esdata1:
   driver: local 
   driver_opts:
      type: none
      device: ./esdata1
      o: bind

It seems that docker-compose do not create the folder if it does not exist , but even when the folder is created before lauching docker I'm always getting this error:

ERROR: for esdata  Cannot create container for service esdata: error while mounting volume with options: type='none' device='./esdata1' o='bind': no such file or directory

NOTE: This is maybe silly, but esdata is the service that use the named volume

  esdata:
    ...
    volumes:
      - esdata1:/usr/share/elasticsearch/data
    ...

What I'm missing here?

Maybe the relative path ./ does not point to the folder where the docker-compose is executed (I've tried with ~/ to use a folder relative the user's home but I got the same error).

Thanks in advance,

PS: If I use an absolute path it works like a charm

Answer 1

I encountered exactly the same issue. It seems that you have done nothing wrong. This is just not yet implemented in Docker : https://github.com/docker/compose/issues/6343

Not very nice for portability...

Answer 2

If you use a named bind mount like this, you must include the full path to the file, eg:

volumes:
  esdata1:
   driver: local 
   driver_opts:
      type: none
      device: /home/username/project/esdata1
      o: bind

That folder must also exist in advance. This is how the linux bind mount syscall works, and when you pass flags like this, you are talking directly to Linux without any path expansion by docker or compose.

If you just want to mount the directory from the host, using a host volume will be expanded for the relative path by compose:

  esdata:
    ...
    volumes:
      - ./esdata1:/usr/share/elasticsearch/data
    ...

While the host volume is easier for portability since the path is automatically expanded, you will lose the feature from named volumes where docker initializes an empty named volume with the image contents (including file permissions/ownership).