Compose: volume driver_opts device does not allow relative paths

[pauldzy]

Docker-compose allows relative paths for most volume commands but does not support such paths when used under driver_opts device

Output of docker-compose version

docker-compose version 1.22.0, build f46880fe
docker-py version: 3.4.1
CPython version: 3.6.6
OpenSSL version: OpenSSL 1.0.2o  27 Mar 201

Output of docker version

Client:
 Version:           18.06.1-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        e68fc7a
 Built:             Tue Aug 21 17:21:34 2018
 OS/Arch:           windows/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.1-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       e68fc7a
  Built:            Tue Aug 21 17:29:02 2018
  OS/Arch:          linux/amd64
  Experimental:     false

Output of docker-compose config
(Make sure to add the relevant -f and other flags)

services:
  foo:
    image: nginx
    volumes:
    - source: C:\mydir\foo
      target: /foo
      type: bind
    - source: foo2
      target: /foo2
      type: volume
version: '3.7'
volumes:
  foo2:
    driver: local
    driver_opts:
      device: ./foo2
      o: bind
      type: none

Steps to reproduce the issue

1. Attempt to use a relative path under driver_opts device

version: "3.7"
services:
    foo:
        image: nginx
        volumes:
            - type: bind
              source: ./foo
              target: /foo
            - type: volume
              source: foo2
              target: /foo2
volumes:
    foo2:
        driver: local
        driver_opts:
            type: none
            o: bind
            device: ./foo2           
 ```

2. docker-compose up

Creating volume "mydir_foo2" with local driver
Creating mydir_foo_1 ... error

ERROR: for mydir_foo_1 Cannot start service foo: error while mounting volume '': error while mounting volume with options: type='none' device='./foo2' o='bind': no such file or directory

ERROR: for foo Cannot start service foo: error while mounting volume '': error while mounting volume with options: type='none' device='./foo2' o='bind': no such file or directory
ERROR: Encountered errors while bringing up the project.
```
providing a full path using /c/ notation corrects the problem.

Expected result

Compose should determine the proper path using the same expansion ;ogic as done for the usual bind mount relative paths.

[codydjango]

I agree this would be nice and could save some head-scratching. The current functionality (driver options passed through directly to drivers) is documented, although it took me a little while to find it. The consistency and ease of use might be worth the addition of path expansion logic.

[klingac]

Same problem in Ubuntu 18.04 with docker compose version

docker-compose version 1.18.0, build 8dd22a9
docker-py version: 2.6.1
CPython version: 2.7.13
OpenSSL version: OpenSSL 1.0.1t  3 May 2016

docker-compose.yml

version: '2.1'

volumes:
  mysql_data:
    driver: local
    driver_opts:
      type: none
      device: /srv/docker/mysql-data
      o: bind

services:
  mysql:
    image: mysql:5.7
    volumes:
      - mysql_data:/var/lib/mysql
    expose:
      - 3306

[smoyav]

Same problem:
volumes: db-data: logs: StorageTest: config: driver: local driver_opts: type: 'none' o: 'bind' device: '/home/${USER}/configs'

[q0015300153]

http://blog.code4hire.com/2018/06/define-named-volume-with-host-mount-in-the-docker-compose-file/

Sorry, my English is very bad.
I stumbled upon this article,
hope it helps you.

[pauldzy]

Thanks for the blog post, all efforts are helpful.

I though think the point of the ticket remains to request that docker-compose should do all this bending-over-backwards for the user. I mean it does exactly this in other places determining the relative path regardless of operating system without the need for squirrelly custom environmental variables.

To my knowledge compose does not do anything we could not script out step-by-step on our own were we so inclined. Rather we use compose cause it makes complicated things easier and simpler to execute. This request is that compose "do its thing" for the bind device pointer and allow us to provide relative paths that compose then converts to an absolute address internally.

That would be swell.

[heakinakai]

I achieved this a while back using the native "$PWD" variable (Linux & Mac). This does not require a custom environment file. So it can be easily achieved using the below syntax. I agree though that they should conform with the other bind syntax and allow for your example. In the meantime, this works well.

volumes: 
    foo2:
        driver: local
        driver_opts:
            type: none
            o: bind
            device: $PWD/foo2

Edit: I believe ${PWD} will work cross-platform, but I don't have a windows docker environment to test this. Hopefully, this helps someone else.

[pauldzy]

Sadly the windows powershell equivalent is lower case $pwd and the equivalent in windows command shell would be the cd command. Those details are generally why we'd want docker-compose to handle this for us. I mean compose already has the logic to know where things are at for other options that take a dot, so the request here to just expand that to the device option.

[kasvtv]

I'm dearly, dearly missing this option. It's hard to handle a lot of volumes if they can't be named, and ${PWD} isnt an option, since it's not cross-platform.

[asamofal]

Guys, what's the reason to not implement relative paths for named volumes?
I'm trying to build docker-compose with mysql percona service, and I'm trying to make configuration of this service is crossplatformed. But how I can create named volume and put it somewhere near the docker-compose.yml if I can't set relative path?? :(

I'm very surprised about this problem.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because it had not recent activity during the stale period.

[Eluminae]

${PWD} isn't an option at all cause it depend too strongly on the context.

• Use docker without the _to risky to be used_ docker group, then you'll have to sudo the docker commands. Then byebye the PWD variable.
• Use the -f ./ops/dev/docker-compose.yml then byebye the true PWD variable

This feature must be implemented cause there is no alternatives.

[bokysan]

It's 2020 and this issue from 2018 still persists.

How do we reopen it?

[lucaspottersky]

@aiordache What do you think? @Eluminae concerns here seems very reasonable.

there is no real alternatives.