| -------------------- | ------------------------------------------------------------------------------------------------------------------ |
| `readonly`, `ro` | If present, causes the bind mount to be [mounted into the container as read-only](#use-a-read-only-bind-mount). |
| `z`, `Z` | Configures SELinux labeling. See [Configure the SELinux label](#configure-the-selinux-label) |
| `rprivate` (default) | Sets bind propagation to `rprivate` for this mount. See [Configure bind propagation](#configure-bind-propagation). |
| `private` | Sets bind propagation to `private` for this mount. See [Configure bind propagation](#configure-bind-propagation). |
| `rshared` | Sets bind propagation to `rshared` for this mount. See [Configure bind propagation](#configure-bind-propagation). |
| `shared` | Sets bind propagation to `shared` for this mount. See [Configure bind propagation](#configure-bind-propagation). |
| `rslave` | Sets bind propagation to `rslave` for this mount. See [Configure bind propagation](#configure-bind-propagation). |
| `slave` | Sets bind propagation to `slave` for this mount. See [Configure bind propagation](#configure-bind-propagation). |
```console {title="Example"}
$ docker run -v .:/project:ro,rshared
```
## Start a container with a bind mount
Consider a case where you have a directory `source` and that when you build the
source code, the artifacts are saved into another directory, `source/target/`.
You want the artifacts to be available to the container at `/app/`, and you
want the container to get access to a new build each time you build the source
on your development host. Use the following command to bind-mount the `target/`
directory into your container at `/app/`. Run the command from within the
`source` directory. The `$(pwd)` sub-command expands to the current working
directory on Linux or macOS hosts.
If you're on Windows, see also [Path conversions on Windows](/manuals/desktop/troubleshoot-and-support/troubleshoot/topics.md).
The following `--mount` and `-v` examples produce the same result. You can't
run them both unless you remove the `devtest` container after running the first
one.
{{< tabs >}}
{{< tab name="`--mount`" >}}
```console
$ docker run -d \
-it \
--name devtest \
--mount type=bind,source="$(pwd)"/target,target=/app \
nginx:latest
```
{{< /tab >}}
{{< tab name="`-v`" >}}
```console
$ docker run -d \
-it \
--name devtest \
-v "$(pwd)"/target:/app \
nginx:latest
```
{{< /tab >}}
{{< /tabs >}}
Use `docker inspect devtest` to verify that the bind mount was created
correctly. Look for the `Mounts` section:
```json
"Mounts": [
{
"Type": "bind",
"Source": "/tmp/source/target",
"Destination": "/app",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
}
],
```
This shows that the mount is a `bind` mount, it shows the correct source and
destination, it shows that the mount is read-write, and that the propagation is
set to `rprivate`.
Stop and remove the container:
```console
$ docker container rm -fv devtest
```
### Mount into a non-empty directory on the container
If you bind-mount a directory into a non-empty directory on the container, the
directory's existing contents are obscured by the bind mount. This can be
beneficial, such as when you want to test a new version of your application
without building a new image. However, it can also be surprising and this
behavior differs from that of [volumes](volumes.md).
This example is contrived to be extreme, but replaces the contents of the
container's `/usr/` directory with the `/tmp/` directory on the host machine. In
most cases, this would result in a non-functioning container.
The `--mount` and `-v` examples have the same end result.
{{< tabs >}}
{{< tab name="`--mount`" >}}
```console
$ docker run -d \
-it \
--name broken-container \
--mount type=bind,source=/tmp,target=/usr \