Bind Mounts

Imagine you’re working at a co-working space with a private office (container) and a shared file room (host directory).

Docker volumes are like filing cabinets inside your private office. The building (Docker) manages them. They’re safe and permanent, but you need to be in your office to access them.

Bind mounts are like setting up a window between your office and the shared file room. You can reach through the window and grab files from the shared room, work on them at your desk, and put them back.

The files aren’t in your office—they’re in the shared room. But you have direct access. And if someone else (another process on your host) modifies a file in the shared room, you immediately see the change through your window.

A bind mount links a host directory to a container directory.

Syntax:

docker run -v /host/path:/container/path image

Or using the more explicit --mount syntax:

docker run --mount type=bind,source=/host/path,target=/container/path image

Example: Mounting source code for development

# Current directory contains your app code
docker run -d \
  --name webapp \
  -v $(pwd):/app \
  -p 8080:8080 \
  node:18

# Or with --mount
docker run -d \
  --name webapp \
  --mount type=bind,source=$(pwd),target=/app \
  -p 8080:8080 \
  node:18

Now:

• Files in $(pwd) on the host appear at /app in the container
• Changes made on the host are immediately visible in the container
• Changes made in the container are immediately visible on the host
• It’s a two-way, real-time sync

Typical development setup:

# Your project structure
myapp/
├── server.js
├── package.json
└── public/
    └── index.html

# Run Node.js with code mounted
cd myapp
docker run -d \
  --name dev-server \
  -v $(pwd):/app \
  -w /app \
  -p 3000:3000 \
  node:18 \
  node server.js

# Edit server.js on your host with VSCode
# Changes are immediately reflected in the container
# Some frameworks support hot-reload, so app updates without restart

Read-only bind mounts:

# Mount configuration as read-only
docker run -v /host/config.yml:/app/config.yml:ro myapp

The :ro flag makes the mount read-only. The container can read the file but can’t modify it.

Permission issues:

On Linux, file permissions are preserved. If a file on the host is owned by user ID 1000, and the container runs as user ID 999, there may be permission conflicts.

Solution:

• Run the container with the same user ID: docker run --user $(id -u):$(id -g) ...
• Or adjust file permissions on the host

Platform differences:

• Linux: Direct, efficient file access
• Mac/Windows: Docker Desktop runs Linux in a VM, so bind mounts go through a translation layer—slightly slower

Host dependencies:

The path must exist on the host. If /host/data doesn’t exist, Docker creates it (as root), which may not be what you want.

Best practice: Create the directory first:

mkdir -p /host/data
docker run -v /host/data:/container/data myimage

Security concerns:

Bind mounts expose host filesystem to containers. A compromised container could modify/delete host files.

Mitigate with:

• Read-only mounts (:ro)
• Minimal host exposure (only mount what’s needed)
• Don’t mount sensitive directories (like /etc, /var)

Use bind mounts when:

• Development (mounting source code for hot-reload)
• Configuration files from the host
• Host data that other processes also access
• You need specific host paths
• Temporary testing/debugging

Use Docker volumes when:

• Production databases
• Persistent application data
• Performance-critical workloads
• Cross-host portability
• Docker-managed backups/migrations

---