Home Explore Blog CI



docker

1st chunk of `content/manuals/engine/storage/bind-mounts.md`
71bbd7a977bd665abf8276286a52a52e562bdd2247aa465a0000000100000fe9
---
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

Title: Bind Mounts in Docker
Summary
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.