docker -v /host:/container relative paths (volume relative path)

[blast-hardcheese]

When volume is specified via a command-line argument, relative paths should be prepended with the current working directory, vs the directory the daemon was started in.

docker run -v data:/var/lib/mydata ... creates and mounts /data.

[creack]

@blast-hardcheese There is no warranty that your client is on the same host as your server.
I though we did return an error in case of non absolute path. If we are not, we should :)

-v should only accept absolute path.

[blast-hardcheese]

Ah, very good point! There is no warning. Should non-absolute paths error out by default, only allowed via an option? In my use-case, filling / with empty directories is not very useful, but I can see how it could be useful in controlled circumstances.

pewter:docker (master) root$ ls -d /contrib
ls: cannot access /contrib: No such file or directory
pewter:docker (master) root$ docker run -v contrib:/tmp/contrib debian:jessie ls /tmp/contrib
pewter:docker (master) root$ ls -d /contrib
/contrib
pewter:docker (master) root$ touch /contrib/file
pewter:docker (master) root$ docker run -v contrib:/tmp/contrib debian:jessie ls /tmp/contrib
file

[tianon]

+1 for relative host paths being a hard error

[ijt]

As of 1.9.1, build a34a1d5, docker doesn't complain about relative paths and fail fast. Instead it merrily chugs along and gives wrong results. I don't mind diving in to make it fail fast if others agree it would be better.

[cpuguy83]

@ijt This is because of named volumes... the syntax has just gotten to overloaded and on top of that auto-creation of volumes makes it impossible to know user intent.
docker service create already has a new syntax (--mount) that's a lot more precise and can catch these kinds of things early.
We'll be bringing that to docker run soon.

[ijt]

Okay, sounds good.

[jayproulx]

Ahh, late to the party, I searched, saw this, and realized if you want a "relative" path you can do this:

docker run -v `pwd`/contrib:/tmp/contrib ...

If you're running from a shell script, this is fine, you're going to be running it from somewhere, great for local development when you're standing up a few images and want to keep those folders handy.

[trajano]

@jayproulx it's too bad that approach does not work with Windows. But we can use %CD%

[bscheshir]

same problem
So... Only run shell directly and execute script inside of container will work 📟

[bscheshir]

In related issue we have solution

Perhaps the relative paths were based on the directory it is run from, not the directory of the file that is running.

i.e. use -w smart

 docker run -it --rm --name py-script-container -v "$PWD":/usr/src/myapp -w /usr/src/myapp/esp8266/tools python:alpine python get.py

instead of

docker run -it --rm --name py-script-container -v "$PWD":/usr/src/myapp -w /usr/src/myapp python:alpine python esp8266/tools/get.py

[farshidz]

I know this is old, but I just made this mistake on Mac and I don't know where I've created a directory on the host (Mac). I ran

docker run -itv temp_docker:/host/temp_docker/ ubuntu bash

Where is temp_docker?

[cpuguy83]

@farshidz It's a named volume that exists in the docker VM.

[tkalfigo]

@farshidz There are 2 types of volumes in Docker: "bind mount" and "managed".

• Bind mount volume syntax:

  -v <host_abs_path>:<abs_path_mount_point> = bind mount volume. You provide absolute path of location on host system and where it should be mounted in the container. Use it when you want to share something from the host system into the container; downside is it creates a dependency of the container on the host it runs on.

• Managed volume syntax:

  -v <abs_path_mount_point> = unnamed managed volume. Docker will create a volume on the host system at a location owned by the docker daemon and mount it in the container at abs_path_mount_point. To find out where docker created the volume on host: docker inspect -f "{{.Mounts}}" ContainerName.

  -v <name>:<abs_path_mount_point> = named managed volume. Same as previous, only instead of volume being assigned a hash, you can provide it with a meaningful name.

[borekb]

Is there an open issue for relative volume mounts, or is it a "won't fix"? If everyone on our team was on Linux or macOS, $PWD is a reasonable workaround but that doesn't work on Windows, and using %CD% on Windows is also not a 100% solution because some users might opt to use different shells than cmd.exe, and if that shell is something like Git Bash or MSYS2 shell, path conversion will kick in so $PWD will not end up being a valid path as received by Docker, etc.

Is there a technical reason why -v .:/path could not be supported by Docker engine? It would make cross-platform invocation so much easier..

[tkalfigo]

@borekb You can use relative paths for volumes, if you go with docker-compose.

For example a trivial docker-compose.yml for an alpine image would be:

version: '3'
services:
    alpi:
        image: alpine
        stdin_open: true
        tty: true
        volumes:
        - ./:/path

Bring it up with docker-compose -p foo up and connect to it with docker exec -it foo_alpi_1 /bin/sh

The folder where docker-compose.yml resides, will be mounted in the container under /path.

[borekb]

@tkalfigo thanks, I am aware that docker-compose supports relative paths so I'm not sure why Docker engine doesn't.

[cpuguy83]

This is a client issue (github.com/docker/cli).

[borekb]

Aha, I re-read the previous more carefully and this is important:

This is because of named volumes [...] docker service create already has a new syntax (--mount) that's a lot more precise and can catch these kinds of things early. We'll be bringing that to docker run soon.

Now I understand better why supporting relative paths in -v is tricky. Are there still plans to implement something like docker run --mount ...? Couldn't find a tracking issue for it.

[cpuguy83]

docker run --mount is already a thing ;)

[borekb]

In stable or some future release? Cannot find a mention of it in the docs. Would be a life saver :)

[cpuguy83]

https://docs.docker.com/storage/bind-mounts/

It's been around for a few releases.

[borekb]

Thanks for the pointer. I'm still confused though: the first paragraph on that page mentions that relative paths should be supported:

When you use a bind mount, a file or directory on the host machine is mounted into a container. The file or directory is referenced by its full or relative path on the host machine.

That doesn't seem to be the case though:

$ docker run --rm -it --mount type=bind,source=example,target=/tmp/mounted ubuntu /bin/bash
C:\Program Files\Docker\Docker\Resources\bin\docker.exe: Error response from daemon: invalid mount config for type "bind": invalid mount path: 'example' mount path must be absolute.

Am I invoking it correctly? Also, does the "response from daemon" mean that it's the Docker engine that rejects the relative path so it's not just a CLI issue?

[cpuguy83]

Am I invoking it correctly? Also, does the "response from daemon" mean that it's the Docker engine that rejects the relative path so it's not just a CLI issue?

Yes.

The docs are definitely incorrect in that regard.

[borekb]

Thanks for confirming. Is this issue still valid then and could be re-opened? Making absolute paths working cross-platform is not easy at all, for example, some npm scripts we have do docker run ... -v $PWD:/... which would be much easier with relative paths. Seems like --mount should have the "luxury" to support that.

[cpuguy83]

It definitely doesn't make sense in this repo as it's totally a client issue. The docker CLI is in github.com/docker/cli.

I can see good reason to support relative paths if for nothing else than to have a compatible syntax with compose...

[borekb]

Thanks, I've created docker/cli#1203.

[Pointotech]

So... is Docker refusing to support relative paths on some philosophical basis, or did I misunderstand this thread? How am I supposed to write documentation for running a Docker VM, without relative paths? Do I have to force every developer to clone their source code to the same location on every machine, just so that my project's setup instructions work with these absolute paths? Seems pretty crazy.

[cpuguy83]

@Pointotech -v $(pwd):/some/path

Also, that is correct we cannot support relative paths from the CLI with -v due to prior overloading of the syntax on -v.
It might be possible with --mount, but likely would require an extra option to signal that the path is relative.

But also, paths would be relative to the daemon not the client.

[robeatoz]

In Windows PowerShell the following command works as mounting relative paths:

docker run -v ${pwd}:/var/lib/mydata