Introduction

Mounting a host directory into a Docker container is the standard way to share files between your machine and the running container. It is especially useful for local development, configuration injection, and inspecting generated output without rebuilding the image every time.

For this specific task, you usually want a bind mount, not a Docker-managed named volume. The two mechanisms are related but solve different problems.

The Simplest Bind Mount

With docker run, the modern syntax is --mount:

1docker run --rm \
2  --mount type=bind,source="$(pwd)",target=/app \
3  python:3.12-slim \
4  ls /app

This mounts the current host directory into /app inside the container.

The older -v form is shorter and still common:

1docker run --rm \
2  -v "$(pwd)":/app \
3  python:3.12-slim \
4  ls /app

Both commands are bind mounts. The difference is mostly readability and explicitness.

Bind Mounts Versus Volumes

Use a bind mount when you want a specific existing host path:

• source code during development
• a config directory
• a host output folder

Use a named volume when Docker should manage the storage location:

• database persistence
• reusable application data across containers
• less dependence on host path layout

For mount this exact host directory into the container, bind mounts are the right answer.

Read-Only Mounts

If the container only needs to read the directory, mount it read-only:

1docker run --rm \
2  --mount type=bind,source="$(pwd)",target=/app,readonly \
3  python:3.12-slim \
4  ls /app

This reduces the risk of the container accidentally changing host files.

With -v, the equivalent is:

-v "$(pwd)":/app:ro

Docker Compose Example

In Docker Compose, the same idea looks like this:

1services:
2  web:
3    image: node:22
4    working_dir: /app
5    command: npm run dev
6    volumes:
7      - ./:/app

This is common for live-reload development setups where the container should immediately see file changes from the host.

Platform Notes

On Linux and macOS, $(pwd) works well in a shell. On Windows PowerShell, path syntax differs. For example:

docker run --rm -v "${PWD}:/app" python:3.12-slim ls /app

Also remember that Docker Desktop may require host-file-sharing permissions for certain directories. If the mount path looks correct but the container sees nothing, host-sharing configuration is worth checking.

What Happens to Existing Container Files

If the container image already contains files at the mount target, the bind mount hides them while the container is running. This surprises people often.

For example, if the image has application code in /app but you bind-mount an empty local directory onto /app, the container will see the empty host directory instead of the image's built-in files.

That behavior is normal. The mount overlays the target path.

File Permissions and Ownership

A mounted directory still uses host filesystem permissions. If the container process cannot read or write the path, the fix is often on the host side or in the container user configuration.

Typical symptoms:

• permission denied on write
• container can see files but cannot modify them
• created files owned by an unexpected UID or GID

For local development, many teams run the container as a user compatible with the host environment to reduce these issues.

Common Pitfalls

The most common mistake is using a named volume when the goal was this exact host folder. Named volumes do not point to an arbitrary path on your machine.

Another common issue is mounting over a path that already contains important files in the image. The mount does not merge directories; it hides the image content at that location.

People also run into shell quoting problems, especially on Windows or when the path contains spaces. Use the shell syntax that matches your environment.

Finally, do not ignore permissions. A mount can be configured correctly and still fail in practice because the container process lacks access to the host directory.

Summary

• To mount a host directory into a container, use a bind mount with --mount or -v.
• Bind mounts are for specific host paths; named volumes are for Docker-managed storage.
• Use read-only mounts when the container should not change host files.
• Remember that a mount hides existing image content at the target path.
• If the mount looks right but does not work, check path syntax, host-sharing settings, and file permissions.