File: get-started/part5.md, CC @johndmulhausen
Step 2 in the Persistent Data section where we need to create a ./data folder on the manager node, isn't working for me because the Redis container outputs the error message invalid mount config for type "bind": bind source path does not exist after deploying the stack. But if I also create a ./data folder on my host (Mac), along with the data folder on the vm (VirtualBox), it will work. Although, no data is stored in the Mac folder. I'm not sure what is the correct way to handle this, probably I had to end my session and connect to the virtual machine again after creating the folder? I use the docker toolbox setup (on an older Mac).
I'm running the latest version of Docker for Mac, and running into what may be a similar issue, oddly enough with a /data dir (but not limited to it). The bind mounts documentation says:
The file or directory does not need to exist on the Docker host already.
Which is not the behavior I'm seeing.
Specifically, bind mounts do seem to work for some directories on the host as a source, notably /tmp:
03077-mbp:~ marc$ docker run -d \
-it \
--rm \
...
--mount type=bind,source=/tmp,target=/data \
...
73f66c914e091d6c830efd0f31b87a03613aaf8d07df1411e895033ad28fc536
Worked fine. I execed into bash, and the mount worked as expected. When I tried to run the same run with /tmp/f, which does not exist, I got:
03077-mbp:~ marc$ docker run -d \
-it \
--rm \
...
--mount type=bind,source=/tmp/f,target=/data \
...
docker: Error response from daemon: invalid mount config for type "bind": bind source path does not exist.
See 'docker run --help'.
Lastly, when I originally tried what I actually wanted, map /data on the host to /data in the container, I got the same as above, except /data does exist on the host, with wide-open permissions:
docker: Error response from daemon: invalid mount config for type "bind": bind source path does not exist.
See 'docker run --help'.
03077-mbp:~ marc$ ls -hla / | grep data
drwxrwxrwx 2 root wheel 68B Oct 1 22:11 data
There's a difference when using the -v or --mount flag; the -v flag (for historic reasons) creates the path, but the --mount flag does not.
From the same page in the documentation ;
If you use -v or --volume to bind-mount a file or directory that does not yet exist on the Docker host, -v will create the endpoint for you. It is always created as a directory.
If you use --mount to bind-mount a file or directory that does not yet exist on the Docker host, Docker does not automatically create it for you, but generates an error.
@thaJeztah thanks so much for calling that out! I missed that in large part because I was confused why it was complaining about a dir that _does_ exist did not, and I'll admit I was flailing a bit. Your comment did lead me to the real issue, which seems like a bug, to me.
As above, when I used --mount type=bind,source=/data,target=/data, I got:
docker: Error response from daemon: invalid mount config for type "bind": bind source path does not exist.
See 'docker run --help'.
When I changed that to -v /data:/data, I got a _very different error_:
docker: Error response from daemon: Mounts denied:
The path /data
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.
TBH, I haven't used docker locally since the boot2docker days, and this setting didn't even occur to me. The [different] response from -v helped me solve the issue in seconds.
IMO:
--mount should emit the same error response as -v. It's odd [to me, not knowing the internals] that -v seems to be the one to carry around more historical baggage, but has the better error response.Again, thank you, @thaJeztah!
It's odd [to me, not knowing the internals] that -v seems to be the one to carry around more historical baggage, but has the better error response.
Docker for Mac uses a proxy for the API, and I suspect that error is added inside that proxy on Docker for Mac (it's not an error that's generated by the "engine"); could you open an enhancement request for that in the Docker for Mac issue tracker? https://github.com/docker/for-mac/issues
Yep, will do.
This content has been rewritten since the issue was filed and I think the problem no longer exists.
When running Docker on macOS, the mini VM (xhyve) may not have the directory you're trying to bind mount. Here's a 1-liner to make those directories _inside_ the VM (not on your macOS filesystem):
$ docker run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i \
mkdir -p /some-required-path
try create mounted directories on host machine(s) before running
For the record.
You may run into this on Windows after you change your Windows account password.
Had the same problem.
Check your firewall configuration too if you changed it lately.
If you uncheck the Shared Drivers and try to recheck it then it will warn you that the firewall is bloquing the feature.
Hope it helps someone.
Thanks @cztomek; that pointed me in the right direction for Mac. For anyone who's on Mac, in your docker preferences under 'File Sharing', make sure that the directory that you're trying to provide for the bind mount is covered by the directories listed there.
For the record.
You may run into this on Windows after you change your Windows account password.
- Open Docker for Windows Settings.
- Click Shared Drives / Reset credentials...
- Share drive once again.
This worked for me. TY!
For MacOS: Depending on where you are binding from Docker might not have permission to access the directory. You can change that by adding Docker under MacOS Settings 禄 Security 禄 Privacy 禄 Full Disk Access. And make sure as well to allow the directory to be bind mounted under Docker Settings Resources 禄 File Sharing
Most helpful comment
For the record.
You may run into this on Windows after you change your Windows account password.