Mount a host directory into a Docker container using docker run -v.

Mounting a host directory into a container is one of those practical skills that makes Docker feel almost magical—you get your code or data inside the container without duplicating files. Here’s the clean, real-world way to do it, plus a quick tour of what’s going on behind the scenes.

The straightforward answer you’ll actually use

Imagine you want a container to read or write files directly from a folder on your machine. The simplest, most common command is:

docker run -v /my/path:/tmp nginx

Here’s the skinny on what’s happening:

• The -v flag creates a bind mount. It connects a path on your host (/my/path) with a path inside the container (/tmp).

• When you start the container, nginx runs as usual, but any file operations in /tmp inside the container touch the same files on your host.

• This is especially handy for sharing configuration, logs, or data between your host and the container, without worrying about copying files back and forth.

Why this particular command works so well

• docker run is the workhorse: it creates a new container and starts it in one go. That means you don’t have to do two steps (create then start); you get a running service right away.

• The -v /host/path:/container/path mapping is the most direct, readable way to say “use this host folder as this folder inside the container.”

• nginx is just the image name here. You could swap in any image you like, and the same mounting pattern applies.

A quick tour of the other options (to save you a detour)

• docker mount -v /my/path:/tmp nginx

• There isn’t a docker mount command like this for creating a mounted container. So this one won’t do the job.

• docker exec -v /my/path:/tmp nginx

• exec runs commands inside an already-running container. It isn’t for mounting the host directory at container start.

• docker create -v /my/path:/tmp nginx

• create makes a container definition but doesn’t start it. You’d still need to run it, and the mounting side of things isn’t the same as doing it at startup.

If you want a more explicit, modern approach

In recent Docker workflows, you’ll sometimes see the --mount flag used, which is a bit more descriptive. Here’s how you’d mount a host directory with that syntax:

docker run --mount type=bind,source=/my/path,target=/tmp nginx

Why consider --mount? It’s clearer to read, and it scales well when you have multiple mounts or more complex setups. The bind mount type behaves the same way as the -v flag in this context; it’s just a different style of doing the same thing.

Two practical patterns you’ll actually use

• Read-write or read-only

• If you want to prevent the container from modifying host files, you can specify a read-only mode:

docker run -v /my/path:/tmp:ro nginx

• If you want full access, omit the :ro and it defaults to read-write on many systems.

• Serving a static site with nginx

• A classic use case is to serve files from a host directory:

docker run -d -p 8080:80 -v /home/me/site:/usr/share/nginx/html:ro nginx

• This spins up nginx in the background, maps host content to nginx’s web root, and exposes it on port 8080. It’s a neat little local web server that’s instant to test.

Common gotchas to watch for

• Make sure the host path exists

• If the folder you’re trying to mount doesn’t exist, you’ll run into errors. Create the folder first, or Docker might fail to mount cleanly.

• Permissions matter

• The container tries to access the host directory with its own user context. If your host directory isn’t accessible to that user, you’ll see permission errors inside the container. Sometimes a quick chmod or chown resolves it; sometimes you’ll adjust the container’s user or use appropriate group ownership.

• Windows and path quirks

• If you’re on Windows, path notation and permissions can behave differently. Use the path style that your Docker engine expects (often under a shared drive) and test with a simple file to confirm access.

• Don’t forget ports

• Mounting a directory doesn’t automatically expose services. If your container runs a web server or another service, you’ll still need to map ports (for example, -p 8080:80) so you can reach it from your host.

A real-world feel for why this matters

Let me explain with a quick mental model: your container is like a software shop inside a tiny glass box. The host directory is the street outside the shop. By mounting the host folder into the container, you’re giving the shop a direct, unfiltered view of what’s on the street. The store can pull in fresh signage, update logos, or log receipts right back to a folder you control. No more ferrying files back and forth in annoying, manual steps.

This approach also mirrors how developers work with codebases. You run a containerized app, but you want to edit configuration, test assets, or log outputs without recreating the image or rebuilding containers each time. Mounting a host directory provides that quick, iterative feedback loop.

A little more nuance, if you’re curious

• The -v shorthand versus --mount

• Both achieve the same goal in this context. If you’re juggling several mounts, --mount often keeps things tidy and explicit.

• Bind mounts versus named volumes

• The examples above are bind mounts (host path mapped into the container). Named volumes are managed by Docker and live in Docker’s own storage area; they’re great for persisting data across container lifecycles, but they don’t map to a host path automatically.

• Security considerations

• Be mindful of what you expose. Mounting a host directory means the container can read and/or write files on the host. Only mount what you need and keep sensitive folders off the mount list unless it’s necessary.

Bringing it all together

So, what’s the bottom line? If you want a container to access files from your machine as if they were part of the container’s filesystem, the simplest, most common approach is:

docker run -v /my/path:/tmp nginx

• The -v flag tells Docker to create a live link between the host directory and the container’s directory.

• The host path (/my/path) and the container path (/tmp) represent where the files live outside and inside the container, respectively.

• The nginx image is just an example—you can swap in anything you’re testing or building.

If you crave a bit more structure, use the --mount syntax:

docker run --mount type=bind,source=/my/path,target=/tmp nginx

Either route gets you that efficient, hands-on integration between your host and your container.

Want to explore more about how Docker handles storage, volumes, and mounts? The official Docker docs are a reliable compass. They walk you through examples, edge cases, and best practices, so you can fine-tune your setups with confidence.

Next time you spin up a container, give that mount a try. A tiny doorway between your host and container can unlock big convenience, especially when you’re juggling code, configs, and logs all in one smooth workflow.

Resources to check out

• Docker’s official documentation on containers, volumes, and mounts

• Community-driven examples and quick-start guides that show real-world patterns

• Practical usage scenarios—serving files, sharing logs, and testing configurations across environments

If you’re curious about more nuanced mounting strategies or want to compare bind mounts to named volumes in different contexts, I’m happy to walk you through specific scenarios. The key idea remains simple: a thoughtful mount can turn a portable container into a flexible, productive teammate for your workflow.