Introduction

To mount the current directory as a volume in Docker on Windows 10, use the -v flag with the appropriate shell variable for the current path. In PowerShell, that is ${PWD}. In Command Prompt, it is %cd%. In Git Bash or WSL, it is $(pwd). The exact syntax depends on which shell you are running, and getting this wrong is the most common reason the mount silently fails or produces an empty directory inside the container.

# PowerShell (most common on Windows 10)
docker run --rm -v ${PWD}:/app -w /app alpine ls -la

:: Command Prompt
docker run --rm -v %cd%:/app -w /app alpine ls -la

# Git Bash / WSL
docker run --rm -v "$(pwd)":/app -w /app alpine ls -la

How Docker Volume Mounts Work

Docker supports two types of mounts for connecting host directories to containers: bind mounts and named volumes. When you mount the current directory, you are using a bind mount. The host path maps directly into the container's filesystem, so changes made on either side are immediately visible to the other.

Host:       C:\Users\dev\project\   <-->   Container: /app/
  index.js                                   index.js
  package.json                               package.json

This is a live, two-way mirror. Files created inside the container at /app appear on the host, and edits made on the host appear inside the container without restarting it.

Bind mount vs named volume

For development workflows where you want to edit code on the host and see changes instantly inside the container, bind mounts are the correct choice.

Shell-Specific Syntax Reference

The variable for "current directory" is different across Windows shells. Using the wrong one produces a confusing error or mounts an empty directory.

Git Bash path conversion issue

Git Bash on Windows automatically converts Unix-style paths to Windows paths, which can break Docker volume mounts. If you see an error about paths not being valid, prefix the path with an extra slash to disable conversion:

# Git Bash: disable MSYS path conversion
docker run --rm -v "/$(pwd)":/app -w //app alpine ls -la

Alternatively, set the MSYS_NO_PATHCONV environment variable:

export MSYS_NO_PATHCONV=1
docker run --rm -v "$(pwd)":/app -w /app alpine ls -la

Docker Desktop Prerequisites

Before volume mounts will work, Docker Desktop must have access to the drive where your project lives.

Enabling file sharing

1. Open Docker Desktop and go to Settings (gear icon).
2. Navigate to Resources, then File Sharing.
3. Ensure the drive containing your project (typically C:\) is listed and enabled.
4. Click Apply and Restart.

Without this step, Docker silently mounts an empty directory. The container starts successfully, but the mounted path contains nothing. This is one of the most confusing failure modes on Windows.

WSL 2 backend vs Hyper-V backend

Docker Desktop on Windows 10 can use either WSL 2 or Hyper-V as its backend. With WSL 2 (recommended), file sharing is handled automatically for paths under \\wsl$\ and most C:\Users\ paths. With the older Hyper-V backend, you must explicitly configure shared drives.

Check which backend you are using in Docker Desktop under Settings, then General, then "Use the WSL 2 based engine."

Practical Examples

Node.js development with live reload

Mount your project directory and use a file watcher like nodemon to reload on changes:

1docker run --rm -it `
2  -v ${PWD}:/app `
3  -w /app `
4  -p 3000:3000 `
5  node:20-alpine `
6  sh -c "npm install && npx nodemon index.js"

Edit index.js on your Windows host, and nodemon inside the container picks up the change automatically.

Python development

1docker run --rm -it `
2  -v ${PWD}:/app `
3  -w /app `
4  python:3.12-slim `
5  python main.py

Docker Compose

In docker-compose.yml, you can use . to refer to the current directory. Compose resolves it relative to the directory containing the docker-compose.yml file:

1services:
2  app:
3    image: node:20-alpine
4    working_dir: /app
5    volumes:
6      - .:/app
7    ports:
8      - '3000:3000'
9    command: sh -c "npm install && npm start"

docker compose up

This is cleaner than typing the -v flag manually and works consistently across shells because Compose handles path resolution internally.

Read-Only Mounts

If the container should read files but never modify them (for example, mounting configuration files), append :ro to the mount:

docker run --rm -v ${PWD}/config:/app/config:ro alpine cat /app/config/settings.json

The container can read everything in /app/config but cannot create, modify, or delete files there.

Debugging Mount Issues

When a mount does not work as expected, use these steps to diagnose:

1# 1. Verify Docker can see the path
2docker run --rm -v ${PWD}:/app alpine ls -la /app
3
4# 2. Check Docker Desktop file sharing settings
5docker info | Select-String "Operating System"
6
7# 3. Inspect mount details on a running container
8docker inspect <container_id> --format '{{json .Mounts}}' | ConvertFrom-Json
9
10# 4. Verify the current directory variable expands correctly
11echo ${PWD}     # PowerShell
12echo %cd%       # cmd.exe

If ls /app shows an empty directory, the most likely causes are: file sharing is not enabled for that drive in Docker Desktop, the path variable is not expanding correctly in your shell, or Git Bash is mangling the path.

File Permission Considerations

Windows and Linux handle file permissions differently. Files created by the container may appear with unexpected ownership on the host, and vice versa. For development, this is usually not a problem. For production containers, specify the user explicitly:

docker run --rm -v ${PWD}:/app -w /app --user 1000:1000 node:20-alpine node index.js

Common Pitfalls

Using the wrong shell variable. ${PWD} works in PowerShell but not in Command Prompt. %cd% works in Command Prompt but not in PowerShell. Mixing them up is the number one cause of failed mounts.

File sharing not enabled in Docker Desktop. The mount succeeds but the directory appears empty inside the container. No error is shown. Check Docker Desktop Settings, then Resources, then File Sharing.

Git Bash path mangling. MINGW's automatic path conversion turns /app into C:\Program Files\Git\app. Use MSYS_NO_PATHCONV=1 or double-slash the container path.

Mounting a path outside the user directory. By default, Docker Desktop only shares paths under C:\Users. Mounting from D:\projects requires adding that path to file sharing settings explicitly.

Performance with large node_modules. Bind mounts on Windows are slower than native filesystem access because Docker must translate between NTFS and the Linux filesystem. For node_modules, consider using a named volume to keep them inside the container:

volumes:
  - .:/app
  - /app/node_modules   # anonymous volume, stays inside container

Summary

• Use -v ${PWD}:/app in PowerShell, -v %cd%:/app in Command Prompt, and -v "$(pwd)":/app in Git Bash or WSL to mount the current directory.
• Bind mounts create a live, two-way mirror between host and container filesystems.
• Docker Desktop must have file sharing enabled for the drive containing your project.
• Git Bash users need to handle MSYS path conversion by setting MSYS_NO_PATHCONV=1 or using double slashes.
• Docker Compose simplifies volume syntax by accepting . as the current directory.
• Append :ro for read-only mounts when the container should not modify host files.
• For performance-sensitive directories like node_modules, use a named or anonymous volume instead of a bind mount.