✦ For everyone, free.

Practical knowledge for real and everyday life

Home

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 Mount Host filesystem path mapped to container path Named Volume Docker-managed persistent storage in Docker area tmpfs In-memory only never written to disk

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:

OptionDescription
roRead-only access inside the container
rwRead-write access (default)
zRelabel the volume for shared SELinux access
ZRelabel the volume for private (non-shared) SELinux access
nocopyPrevent 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
SyntaxShort, implicitExplicit key-value pairs
Creates host dir if missingYes (bind mounts)No — requires dir to exist
Multiple optionsColon-separated suffixesComma-separated key=value
Readability in scriptsCompactSelf-documenting
Supported typesbind, volume, tmpfsbind, volume, tmpfs, npipe