Bind Source Path

The bind source path is the specific, existing location on the host filesystem that a bind mount exposes inside a container, and it must always be specified as an absolute path, distinguishing a bind mount syntactically from a named volume reference.

Specifying the Source Path

The source path appears first in the -v flag's mapping, before the colon separating it from the container-side target path.

docker run -d -v /home/user/app-data:/app/data myapp:1.0

Here, /home/user/app-data is the bind source path — an absolute path on the host filesystem.

Why the Source Must Be Absolute

Docker distinguishes a bind mount from a named volume specifically by whether the source begins with a / (or, on Windows, a drive letter) — a relative-looking name instead is interpreted as a named volume reference rather than a host path.

docker run -d -v app-data:/app/data myapp:1.0
docker run -d -v /home/user/app-data:/app/data myapp:1.0

The first command references a named volume called app-data; the second references an actual host path at that absolute location — syntactically similar but referring to fundamentally different storage mechanisms.

Using a Relative Path Resolved at Invocation Time

While the source itself must be absolute in the actual Docker API call, shell expansion can be used to conveniently specify a path relative to the current working directory at the time the command is run.

docker run -d -v $(pwd)/data:/app/data myapp:1.0

This resolves to an absolute path before being passed to Docker, achieving the convenience of a relative-feeling reference while still satisfying the absolute path requirement.

Verifying the Source Path Is Correct

Confirming the bind mount is referencing the intended host location avoids a subtle mistake where a similarly named but incorrect path was accidentally specified.

docker inspect myapp --format '{{json .Mounts}}'

Why Understanding the Bind Source Path Matters

Correctly specifying an absolute bind source path, and understanding how it's syntactically distinguished from a named volume reference, is essential for reliably mounting the intended host content rather than accidentally creating or referencing an unrelated named volume instead.