After upgrading to v1.12.0-beta18-3-gec40b14 this morning, a previously working container suddenly started failing as follows:
docker: Error response from daemon: Mounts denied:
The path /var/folders/f5/t48vxz555b51mr3g6jjhxv400000gq/T/tmp.DkXBAOUx
is not shared from OS X and does not belong to the system.
You can configure shared paths from Docker -> Preferences...
..
[exit code: 125]
Before I go futzing with the shared path preferences, I want to make sure nothing else is broken here since this used to work fine until this latest update.
If I look in the “File sharing” pane under Preferences, I see the following paths:
/Users
/Volumes
/tmp
/private
I’ve never edited these settings. Should /var be in there? Did the defaults for these paths change recently?
Information
Docker for Mac: version: mac-v1.12.0-beta18-3-gec40b14
OS X: version 10.11.5 (build: 15F34)
logs: /tmp/20160706-111308.tar.gz
[OK] docker-cli
[OK] app
[OK] menubar
[OK] virtualization
[OK] system
[OK] osxfs
[OK] db
[OK] slirp
[OK] moby-console
[OK] logs
[OK] vmnetd
[OK] env
[OK] moby
[OK] driver.amd64-linux
I don’t have a simple repro for this now, but if the issue is not easy to find from this limited description I can definitely try to cook a minimal repro up.
Could you share the docker run invocation that you are using?
/var is not intended to be shared and typically cannot be shared as-is due to collision with /var in the Docker for Mac Linux VM. Subdirectories of /var could possibly be shared. /var/folders/f5/... looks like a specially created system directory. Are you using some tool that wraps docker like docker-compose?
Thanks for participating in the Docker for Mac Beta!
Here’s the docker run invocation that’s resulting in the error I reported:
docker run \
-t \
--rm \
-v /var/folders/f5/t48vxz555b51mr3g6jjhxv400000gq/T/tmp.567srJ24:/setperms.sql mmds/vsql \
[vsql parameters snipped] \
-a -e -f /setperms.sql
The ugly /var path is being generated by an earlier call to mktemp. And if I understood the run command correctly, it appears that we are sharing a specific subdirectory of /var, so in theory this should be OK, no?
Since the behavior of mktemp on my system probably didn’t change recently, I’m wondering if something about Docker was changed in a recent release that made this suddenly stop working.
Indeed, Beta 18 includes user-configurable OS X export directories rather than the previously-fixed set of /Users, /Volumes, /tmp, and /private. When merging the Linux and OS X file system namespaces, the rule is that non-existent directories that are not under an export path will not be automatically created. I recommend explicitly creating the shared directory path in the VM with something like docker run --rm -v /:/host alpine mkdir -p /host/$PATH before passing it to docker run. We are currently preparing a hotfix for some unrelated issues with Beta 18 but documentation about this new behavior will be online soon.
Sure, so this will run the alpine:latest image which is pretty minimal (maybe 2MB download). Inside that container, it will execute mkdir -p to create the given path. If the environment variable $PATH contains the path that you want to bind mount into your other container (and that doesn’t exist and you’d like Docker to create), then this command will run a container that creates that path in the Moby Linux VM rather than on the OS X host.
Hey can you explain to me how did you adjust mktemp to use /tmp?
I tried to change $TMPDIR path to /tmp, but whenever I call mktemp it creates in /var/folders…