These volumes persist even after the container has been deleted, and can be shared with other containers.

You can create a named volume with a command like docker volume create new_vol, and then share it into the container using the -v flag again:ĭocker run -it -v new_vol:/my_files ubuntu bash The second option, a named volume, is a filesystem managed by Docker. This is very simple and convenient, but if you’re using Docker Desktop a named volume may have better performance, for reasons I’ll explain in the next section. Then the files at /users/stephen will be available at /my_files in the container, and you can read and write to them there. For example, if you runĭocker run -it -v /users/stephen:/my_files ubuntu bash The first option most people encounter is the bind mount, where part of your local filesystem is shared with the container.

Both of these use the -v flag to docker run to specify some files to share with the container. So the natural next questions are, how can I see my other files? And how can my container write data that I can read later and maybe use in other containers? This is where bind mounts and volumes come in. You’ll quickly find that (1) the container has its own filesystem, based on the filesystem in the Ubuntu image (2) you can create, delete and modify files, but your changes are local to the container and are lost when the container is deleted (3) the container doesn’t have access to any other files on your host computer. Suppose you run an Ubuntu container with docker run -it ubuntu bash. How do I see my source code inside my container? What’s the difference between a volume and a bind mount? Why is file sharing slower than on Linux, and how can I speed it up? In this blog post, I’ll cover the options you have, some tips and tricks, and finish with a sneak preview of what we’re currently working on. In order to make things more portable, you may want to test which platform you are currently running on, and if it's macOS, prefix the mount path with /private.One of the topics users of Docker Desktop often ask us about is file sharing. If you change the path to /private/var, then it will succeed, because macOS exports the entire /private filesystem tree for mounting. Therefore, the path is not available, and the mount fails. var exists in the Linux VM, but /var/folders does not.

In your case, /var is not exported by macOS. If neither of them have the path you requested, then the mount fails. If there is no match there, the Linux VM where Docker is running is checked next. When you ask for a volume mount, macOS filesystem exports are checked first. Note that /var/run is specifically mentioned here as a place that would be mounted from the Linux VM, instead of from macOS. Paths that already exist in the VM and contain files are reserved by Docker and cannot be exported from macOS. If a macOS path is not shared and does not exist in the VM, an attempt to bind mount it will fail rather than create it in the VM. (See Preferences.)Īll other paths used in -v bind mounts are sourced from the Moby Linux VM running the Docker containers, so arguments such as -v /var/run/docker.sock:/var/run/docker.sock should work as expected. To add or remove directory trees that are exported to Docker, use the File sharing tab in Docker preferences whale Why is /tmp listed in the sharing panel, but /var is not (even though both are a part of /private)? Docker for Mac's documentation about filesystem namespaces explains:īy default, you can share files in /Users/, /Volumes/, /private/, and /tmp directly. That is also true for /tmp: $ ls -ld /tmp 1 root wheel 11 Jan 26 16:18 /tmp -> 1 root wheel 11 Jan 26 16:18 /var -> private/var var in macOS is a symbolic link into /private. This is mostly because Docker tries to comply with Apple's filesystem sandbox guidelines.Īs shown in Docker's preferences, only certain paths are exported by macOS. Docker for Mac volume mounts behave differently than the base Docker system.

Docker for mac file sharing