🚨 Docker Error Guide: 'Mounts denied: The path is not shared from the host' — Desktop File Sharing

Overview

Docker Desktop for Mac and Windows raises this when you bind-mount a host directory that has not been shared with the Docker VM. It appears on docker run -v or docker compose up:

docker: Error response from daemon: Mounts denied: The path /Users/dev/projects/myapp is not shared from the host and is not known to Docker.

Docker Desktop runs the Linux daemon inside a lightweight VM. Only host directories explicitly exposed to that VM can be bind-mounted. When you point -v at a path outside the shared list, the VM cannot see it and the mount is denied. This is a Docker Desktop (Mac/Windows) issue; native Linux daemons do not have this restriction.

Symptoms

• docker run -v /Users/dev/projects/myapp:/app ... fails immediately with Mounts denied.
• docker compose up fails on a service whose bind-mount path lives outside your home directory.
• The same command works for a colleague whose file-sharing settings include the path.
• Paths under the default shared roots (like /Users on Mac) work, but paths on external drives or /private/tmp do not.
• On Windows, a mount from a drive not shared in Docker Desktop settings is denied.

Common Root Causes

• Path outside the configured file-sharing list — Docker Desktop only exposes a defined set of host directories to the VM.
• External or network drives — volumes on external disks, mounted network shares, or non-default mount points are not shared by default.
• A different user’s home directory or a system path like /private/etc that is not in the shared roots.
• Windows drive not enabled for sharing in Docker Desktop’s Resources settings.
• Symlinks pointing outside shared roots — the real target resolves to an unshared location.
• Typo or wrong absolute path that does not exist under any shared root.

Diagnostic Workflow

First confirm the exact host path Docker is trying to mount and that it exists:

ls -ld /Users/dev/projects/myapp
docker run --rm -v /Users/dev/projects/myapp:/app alpine ls /app

Open Docker Desktop’s file-sharing configuration and compare it against your mount path:

• macOS/Windows: Docker Desktop → Settings → Resources → File Sharing. The listed directories are the only host roots the VM can bind-mount.

Inspect what a Compose service is actually mounting so you know which path to share:

docker compose config | grep -A3 volumes

If you prefer the CLI, the shared-paths list also lives in Docker Desktop’s settings file; the GUI is the supported way to edit it. After adding a path, apply and restart:

• Click +, add the parent directory (for example /Users/dev/projects), then Apply & Restart.

Verify the mount works after the restart:

docker run --rm -v /Users/dev/projects/myapp:/app alpine ls /app

Example Root Cause Analysis

A developer keeps a project on an external SSD at /Volumes/WorkSSD/myapp and runs:

docker run -v /Volumes/WorkSSD/myapp:/app myapp:1.4.2
# Mounts denied: The path /Volumes/WorkSSD/myapp is not shared from the host and is not known to Docker.

Docker Desktop’s File Sharing list contains only /Users, /Volumes is not present, so the VM cannot see the external drive. The fix is to add the drive’s mount root to file sharing:

1. Docker Desktop → Settings → Resources → File Sharing.
2. Add /Volumes/WorkSSD (or /Volumes).
3. Click Apply & Restart.

After the restart, the VM exposes the external drive and the mount succeeds:

docker run --rm -v /Volumes/WorkSSD/myapp:/app alpine ls /app
# (project files listed)

An alternative that avoids host sharing entirely is to use a named volume and copy data in, which keeps everything inside the Docker VM.

Prevention Best Practices

• Keep project directories under a shared root (the default /Users on Mac, enabled drives on Windows) so bind-mounts work without extra configuration.
• Document required file-sharing paths in your project README so new contributors configure Docker Desktop once.
• For paths on external or network drives, add the mount root to File Sharing during machine setup.
• Prefer named volumes over host bind-mounts for data that does not need to live on the host filesystem.
• On Windows, enable each drive letter you mount from in Docker Desktop’s Resources settings.
• Resolve symlinks to confirm the real target lives inside a shared root before mounting.

Quick Command Reference

# Confirm the host path exists
ls -ld /Users/dev/projects/myapp

# See exactly what a Compose service mounts
docker compose config | grep -A3 volumes

# Test a bind-mount after sharing the path
docker run --rm -v /Users/dev/projects/myapp:/app alpine ls /app

# Docker Desktop file-sharing settings:
# Settings -> Resources -> File Sharing -> add path -> Apply & Restart

Conclusion

Mounts denied: The path is not shared from the host is a Docker Desktop restriction: the Linux VM can only bind-mount host directories that appear in its File Sharing list. Confirm the exact path, add its root under Settings → Resources → File Sharing, and Apply & Restart — or sidestep host sharing with a named volume. Keeping projects under a shared root avoids the error for good. For more volume and mount fixes, see the Docker guides.