19.2.1.5 Run Volume Option
A focused guide to Run Volume Option, connecting core concepts with practical Docker and container operations.
The volume option in docker run controls how storage is connected to a container. Containers have an ephemeral writable layer that disappears when the container is removed. The -v (or --volume) flag and the newer --mount flag allow attaching persistent or shared storage to a container — from the host filesystem, from a named Docker volume, or from an in-memory filesystem — so that data outlives the container that created it.
Three Types of Storage Attachments
Docker supports three storage types, all configurable through the -v or --mount flags:
Bind Mounts
A bind mount maps a specific path on the host filesystem to a path inside the container. Both the host and the container see the same files in real time.
docker run -d -v /host/data:/app/data myapp:1.0.0
The left side of the : is the host path; the right side is the container path. If the host path does not exist, Docker creates it as a directory.
Any file created in /app/data inside the container immediately appears in /host/data on the host, and vice versa.
Read-Only Bind Mount
To prevent the container from modifying the host path:
docker run -d -v /host/config:/app/config:ro myapp:1.0.0
The :ro suffix makes the mount read-only inside the container. Writes to /app/config will fail with a read-only filesystem error.
Using Relative Paths with $(pwd)
docker run -d -v "$(pwd)/data":/app/data myapp:1.0.0
Or on Windows PowerShell:
docker run -d -v "${PWD}/data:/app/data" myapp:1.0.0
Named Volumes
Named volumes are Docker-managed storage areas. Unlike bind mounts, the host path is chosen and managed by Docker itself (typically under /var/lib/docker/volumes/). Named volumes persist until explicitly deleted with docker volume rm.
docker run -d -v mydata:/app/data myapp:1.0.0
If mydata does not exist, Docker creates it automatically. If it already exists, its contents are available inside the container at /app/data.
Named volumes are portable: they can be backed up, shared between containers, and moved to different hosts. They do not depend on the host's directory structure.
Sharing a Named Volume Between Containers
docker run -d -v shared-cache:/cache service-a:1.0.0
docker run -d -v shared-cache:/cache service-b:1.0.0
Both containers have full read-write access to the same volume data.
Anonymous Volumes
Specifying only the container path creates an anonymous volume — a named volume with an automatically generated UUID as its name:
docker run -d -v /app/data myapp:1.0.0
Anonymous volumes persist after the container is removed unless --rm is used, at which point Docker removes the anonymous volume with the container.
The --mount Flag
--mount is the more verbose but explicit alternative to -v. It uses key-value pairs:
# Named volume
docker run -d --mount type=volume,source=mydata,target=/app/data myapp:1.0.0
# Bind mount
docker run -d --mount type=bind,source=/host/data,target=/app/data myapp:1.0.0
# Read-only bind mount
docker run -d --mount type=bind,source=/host/config,target=/app/config,readonly myapp:1.0.0
# tmpfs
docker run -d --mount type=tmpfs,target=/tmp myapp:1.0.0
--mount does not create the source directory automatically for bind mounts — it requires the directory to exist. This avoids silent misconfiguration where a typo in the path causes Docker to create an empty directory instead of mounting the intended one.
tmpfs Mounts
A tmpfs mount stores data in the host's RAM, never writing it to disk. This is appropriate for sensitive data (credentials, tokens) or temporary processing data where persistence is not desired.
docker run -d --tmpfs /tmp myapp:1.0.0
Or with --mount:
docker run -d --mount type=tmpfs,target=/tmp,tmpfs-size=128m myapp:1.0.0
Data in a tmpfs mount is lost when the container stops.
Volume Mount Options
Both -v and --mount support additional options:
| Option | Description |
|---|---|
ro | Read-only access inside the container |
rw | Read-write access (default) |
z | Relabel the volume for shared SELinux access |
Z | Relabel the volume for private (non-shared) SELinux access |
nocopy | Prevent Docker from copying container path contents into a new named volume at creation |
SELinux labels:
docker run -d -v /host/data:/app/data:z myapp:1.0.0
Inspecting Volume Mounts on a Running Container
docker inspect --format '{{json .Mounts}}' my-container
Or:
docker inspect my-container | grep -A 20 '"Mounts"'
Managing Named Volumes
# List all volumes
docker volume ls
# Inspect a volume
docker volume inspect mydata
# Remove a volume
docker volume rm mydata
# Remove all unused volumes
docker volume prune
Differences Between -v and --mount
| Feature | -v | --mount |
|---|---|---|
| Syntax | Short, implicit | Explicit key-value pairs |
| Creates host dir if missing | Yes (bind mounts) | No — requires dir to exist |
| Multiple options | Colon-separated suffixes | Comma-separated key=value |
| Readability in scripts | Compact | Self-documenting |
| Supported types | bind, volume, tmpfs | bind, volume, tmpfs, npipe |