Preferences UI resolves symlinks in shared paths, but docker run -v doesn't

[barisione]

Description:

docker run (on macOS Sierra) doesn't resolve symlinks passed with -v, so it complains that the path is not mountable.
The Preferences UI does resolve symlinks so you cannot add the directory that failed mounting to your list of allowed directories.

Note that I initially reported this on the generic docker tracker as I thought that the Preferences UI was reasonable.

Steps to reproduce the issue:

1. Verify that /var is a symlink to /private/var on macOS (this is the normal behaviour).
2. Verify that the Docker configuration contains /private in the list of directories which can be mounted (Docker... -> Preferences -> File Sharing).
3. Run docker run -v /var/folders/foo:/foo true.
4. Get an error about /var/folders/foo not being shared.
5. Try to add /var/folders/foo to the list of shared folders.
6. Get an error because “The export path /private/var/foo overlaps with the export path /private.”.

Describe the results you received:

When doing docker run:

docker: Error response from daemon: Mounts denied:
The path /var/folders/foo
is not shared from OS X and is not known to Docker.
You can configure shared paths from Docker -> Preferences... -> File Sharing.
See https://docs.docker.com/docker-for-mac/osxfs/#namespaces for more info.

When trying to add the path in the preferences:

The export path /private/var/foo overlaps with the export path /private.

Describe the results you expected:

I would expect either docker run to cope with symlinks by resolving them or the preferences dialog to allow adding paths with symlinks.

Output of docker version:

Client:
 Version:      1.13.0
 API version:  1.25
 Go version:   go1.7.3
 Git commit:   49bf474
 Built:        Wed Jan 18 16:20:26 2017
 OS/Arch:      darwin/amd64

Server:
 Version:      1.13.0
 API version:  1.25 (minimum version 1.12)
 Go version:   go1.7.3
 Git commit:   49bf474
 Built:        Wed Jan 18 16:20:26 2017
 OS/Arch:      linux/amd64
 Experimental: true

Output of docker info:

Containers: 54
 Running: 2
 Paused: 0
 Stopped: 52
Images: 40
Server Version: 1.13.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 157
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host ipvlan macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 03e5862ec0d8d3b3f750e19fca3ee367e13c090e
runc version: 2f7393a47307a16f8cee44a37b262e8b81021e3e
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.4-moby
Operating System: Alpine Linux v3.5
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.952 GiB
Name: moby
ID: D6YQ:LVUU:NFES:MJAW:73F5:T4DH:HZHB:Q7GW:F6BK:OGES:FEKB:XKBD
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 29
 Goroutines: 36
 System Time: 2017-02-03T19:00:50.848113147Z
 EventsListeners: 1
No Proxy: *.local, 169.254/16
Registry: https://index.docker.io/v1/
Experimental: true
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

[dsheets]

Hi @barisione, this feature is indeed confusing when it comes to exporting symlinks. The basic idea is that the command line that you invoke is exactly the command line that the docker daemon sees so only paths exported from the Docker for Mac Preferences are available (as you point out). You can export and mount subdirectories of /var by selecting a path (or the first blank line) in the File Sharing preference pane and then clicking on the selected path (or first blank line) again to edit it. In this way, you should be able to export /var/folders and perform the bind mount you describe.

I have marked this issue as related to the GUI, bind mounts, and documentation as I think we could make the functionality I describe above much clearer. I'd be interested in hearing from you about what would help to discover this functionality or how the behavior could be changed to make it more intuitive. The primary constraint we have is that -v bind mounts can source directories from both the VM (e.g. /var/run/docker.sock) and the host (e.g. /Users). To do this, we rely on the file system name spaces being largely disjoint in the two operating systems. This means that we can't easily let users bind mount /var from the host as it already exists in Linux. I hope this helps explain the issue. Thanks for your report and for using Docker for Mac!

[barisione]

For me it's not a big problem, I just need to resolve the symlink before passing it to docker.
Maybe the UI could be improved by giving a different more clear error message?

[mandarg]

@dsheets It took me a couple reads to understand what you were saying about the blank line selection, and you are right – it's definitely not obvious. After understanding what I needed to do, it did solve my problem though. Thanks! 😄

Since you were looking for suggestions about how to make the behaviour more intuitive, here's one – would it be possible to make the default way of adding paths to the File Sharing Preference pane be the "blank line" method? That is, when a user clicks the + to add a new path, they are given a new blank line with a cursor where they can type in their path, (in the above case, /var/folders/ rather than the Finder selection (which will auto-resolve the symlink, thereby leading to further problems).

Since Docker users have to use the CLI extensively anyway, I would think that this way would be more intuitive for most of them. The current way, where clicking the + puts you into a Finder selection pane(?) could perhaps be retained through an alternate method, like a folder icon or something.

[Caveat: I have no idea how difficult any of this would be, and my suggestion might reflect that.]

[docker-robott]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked