8.3.1.2 Bind Target Path

The bind target path is the location inside the container's own filesystem where a bind-mounted host path becomes accessible, determined entirely by the application's expectations about where it should look for that particular content.

Specifying the Target Path

The target path appears after the colon in the -v flag's mapping, specifying exactly where within the container's filesystem the host content should appear.

docker run -d -v /home/user/config:/etc/myapp/config myapp:1.0

The application inside this container should be configured (or expect by convention) to look for its configuration specifically at /etc/myapp/config, since that's where this bind mount makes the host content available.

Choosing an Appropriate Target Path

The target path should match wherever the containerized application actually expects to find the relevant content — mounting to an unexpected location provides no benefit if the application never looks there.

ENV CONFIG_PATH=/app/config

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

The target path here matches the location the application has been configured to expect, ensuring the bind-mounted content is actually used.

What Happens if the Target Path Already Has Content

If the target path already contains files from the image (rather than being an empty directory), mounting a bind mount there typically obscures that original content for the duration of the mount, replacing it entirely with the host-provided content instead.

docker run -d -v /home/user/custom-html:/usr/share/nginx/html nginx:alpine

This replaces nginx's default HTML content entirely with whatever is present in the host's custom-html directory.

Verifying the Target Path Is Correctly Populated

Confirming the expected content actually appears at the target path inside the running container validates the bind mount is configured correctly.

docker exec myapp ls /etc/myapp/config

Why Understanding the Bind Target Path Matters

Correctly choosing a bind mount's target path — matching exactly where the containerized application expects to find the relevant content — is essential for the mount to actually have its intended effect, rather than silently mounting host content to a location the application never references.