Bind Mounts in Docker

--- description: Using bind mounts title: Bind mounts weight: 20 keywords: storage, persistence, data persistence, mounts, bind mounts aliases: - /engine/admin/volumes/bind-mounts/ - /storage/bind-mounts/ --- When you use a bind mount, a file or directory on the host machine is mounted from the host into a container. By contrast, when you use a volume, a new directory is created within Docker's storage directory on the host machine, and Docker manages that directory's contents. ## When to use bind mounts Bind mounts are appropriate for the following types of use case: - Sharing source code or build artifacts between a development environment on the Docker host and a container. - When you want to create or generate files in a container and persist the files onto the host's filesystem. - Sharing configuration files from the host machine to containers. This is how Docker provides DNS resolution to containers by default, by mounting `/etc/resolv.conf` from the host machine into each container. Bind mounts are also available for builds: you can bind mount source code from the host into the build container to test, lint, or compile a project. ## Bind-mounting over existing data If you bind mount file or directory into a directory in the container in which files or directories exist, the pre-existing files are obscured by the mount. This is similar to if you were to save files into `/mnt` on a Linux host, and then mounted a USB drive into `/mnt`. The contents of `/mnt` would be obscured by the contents of the USB drive until the USB drive was unmounted. With containers, there's no straightforward way of removing a mount to reveal the obscured files again. Your best option is to recreate the container without the mount. ## Considerations and constraints - Bind mounts have write access to files on the host by default. One side effect of using bind mounts is that you can change the host filesystem via processes running in a container, including creating, modifying, or deleting important system files or directories. This capability can have security implications. For example, it may affect non-Docker processes on the host system. You can use the `readonly` or `ro` option to prevent the container from writing to the mount. - Bind mounts are created to the Docker daemon host, not the client. If you're using a remote Docker daemon, you can't create a bind mount to access files on the client machine in a container. For Docker Desktop, the daemon runs inside a Linux VM, not directly on the native host. Docker Desktop has built-in mechanisms that transparently handle bind mounts, allowing you to share native host filesystem paths with containers running in the virtual machine. - Containers with bind mounts are strongly tied to the host. Bind mounts rely on the host machine's filesystem having a specific directory structure available. This reliance means that containers with bind mounts may fail if run on a different host without the same directory structure. ## Syntax To create a bind mount, you can use either the `--mount` or `--volume` flag. ```console $ docker run --mount type=bind,src=<host-path>,dst=<container-path> $ docker run --volume <host-path>:<container-path> ``` In general, `--mount` is preferred. The main difference is that the `--mount` flag is more explicit and supports all the available options. If you use `--volume` to bind-mount a file or directory that does not yet exist on the Docker host, Docker automatically creates the directory on the host for you. It's always created as a directory. `--mount` does not automatically create a directory if the specified mount path does not exist on the host. Instead, it produces an error: ```console $ docker run --mount type=bind,src=/dev/noexist,dst=/mnt/foo alpine docker: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /dev/noexist. ``` ### Options for --mount The `--mount` flag consists of multiple key-value pairs, separated by commas

Bind mounts allow mounting files or directories from the host machine into a container. They are useful for sharing code, persisting files generated in containers, and sharing configuration files. Bind mounts can obscure existing data in the container and have considerations such as write access to the host filesystem, creation on the daemon host, and strong ties to the host's filesystem. The `--mount` and `--volume` flags can be used to create bind mounts, with `--mount` being preferred for its explicitness and support for all options. The `--mount` flag doesn't create source directories automatically and will error if it doesn't exist.