Relative paths no longer accepted as bind mounts

[maxpfingsthorn]

I'm on Docker 1.9.1:

max ~$ docker version
Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   a34a1d5
 Built:        Fri Nov 20 13:12:04 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   a34a1d5
 Built:        Fri Nov 20 13:12:04 UTC 2015
 OS/Arch:      linux/amd64

max ~$ docker info
Containers: 1
Images: 79
Server Version: 1.9.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 81
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.16.0-57-generic
Operating System: Ubuntu 14.04.3 LTS
CPUs: 8
Total Memory: 15.63 GiB
Name: max
ID: 6MM5:N3GU:FHW3:UD63:CW4I:3ZQK:5BOB:IHDN:UZAD:QCKQ:SCXE:ZKDA

This is running on the physical machine, no VMs.

List the steps to reproduce the issue:

max ~$ docker pull ubuntu:trusty
max ~$ docker run -it --rm -v .:/test:ro ubuntu:trusty 
Error response from daemon: . includes invalid characters for a local volume name, only [a-zA-Z0-9][a-zA-Z0-9_.-] are allowed

It seems that since #16433 (specifically since @a7e686a779523100a092acb2683b849126953931), relative paths are rejected as bind mounts (see ParseVolumeSource in volume/volume_unix.go:127). Only absolute paths are accepted, treating all other input as volume names. Thus, using a relative path (as described in many docs, both for Docker Engine and Docker Compose (actually in the very first example!)) is no longer possible and results in an error message.
I would suggest the following rule to resolve this issue: If the spec is a valid volume name (given the regex in utils.RestrictedVolumeNamePattern), use it as a volume name, and as a bind path otherwise. This effectively rejects names starting with a dot, tilde, or slash. Though a cleaner way would be to check if such a volume name exists (in reference to #16072).

import (
    "github.com/docker/docker/utils"
)

func ParseVolumeSource(spec string) (string, string) {
    if utils.RestrictedVolumeNamePattern.MatchString(spec) {
        return spec, ""
    }
    return "", spec
}

[GordonTheTurtle]

If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.

If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.

For more information about reporting issues, see CONTRIBUTING.md.

You don't have to include this information if this is a feature request

(This is an automated, informational response)

---

BUG REPORT INFORMATION

Use the commands below to provide key information from your environment:

docker version:
docker info:

Provide additional environment details (AWS, VirtualBox, physical, etc.):

List the steps to reproduce the issue:
1.
2.
3.

Describe the results you received:

Describe the results you expected:

Provide additional info you think is important:

----------END REPORT ---------

#ENEEDMOREINFO

[vdemeester]

Hi @maxpfingsthorn

From the dockervolumes page :

The container-dir must always be an absolute path such as /src/docs. The host-dir can either be an absolute path or a name value.

It has been this way for a long time I think. It was already the case in June for example (so it was the 1.6 or 1.7).

The example you gave is from docker/compose which does additionnal stuff (and one of them is to translate a relative directory to an absolute before sending it to the API).

[maxpfingsthorn]

But I'm talking about the host-dir bit. I'm saying that if the host-dir is not absolute, it is treated as a volume name instead. But I really want to use a relative host-dir.

[maxpfingsthorn]

Ah, ok, I get it now. Sorry for the noise.

I came across #4929 and #4830, explaining the behavior as it is.

Docker compose works as expected.