The Docker daemon failed to start a container because the host path specified for a bind mount volume does not exist. This is a common error because Docker expects the source path on your machine to be present before it can mount it into the container.
Here are the most common reasons this happens and how to fix them:
1. Typo in the Host Path
The simplest explanation is often the correct one: a simple typo in the path you provided to Docker. This could be a missing slash, an extra character, or a misspelled directory name.
Diagnosis:
Carefully examine the path specified in your docker run command or docker-compose.yml file. Compare it character-by-character to the actual path on your host machine.
Fix:
Correct the typo. For example, if you intended to mount /home/user/myproject/data but typed /home/user/myproject/dta, change it to:
docker run -v /home/user/myproject/data:/app/data your_image
Why it works: Docker will now look for the correctly spelled directory on your host and mount it as expected.
2. Relative Paths Not Resolving Correctly
When using relative paths (e.g., . or ../data) in your docker run command or docker-compose.yml, Docker resolves them relative to the directory where the command is executed or where the docker-compose.yml file is located. If you’re running the command from an unexpected directory, the relative path won’t point to the intended location.
Diagnosis:
If using relative paths, check your current working directory (pwd). Ensure this is the directory from which the relative path should be resolved.
Fix: Either: a) Navigate to the correct directory before running the Docker command:
cd /path/to/your/project
docker run -v ./data:/app/data your_image
b) Use an absolute path instead of a relative one. To get the absolute path of the current directory, you can use $(pwd):
docker run -v "$(pwd)/data":/app/data your_image
Why it works: Using $(pwd) ensures that the path Docker sees is always absolute and correctly resolved, regardless of your current working directory.
3. The Directory Was Never Created
You might have assumed the directory exists, but it was never actually created on your host system.
Diagnosis:
Use ls -ld /path/to/your/host/directory to check if the directory exists. If it returns an error like "No such file or directory," it doesn’t exist.
Fix: Create the directory on your host machine:
mkdir -p /path/to/your/host/directory
The -p flag ensures that any parent directories that don’t exist are also created.
Why it works: Docker can now find and mount the directory because it has been created on the host.
4. Permissions Issues on Parent Directories
While the immediate source path might be intended to exist, Docker (specifically the user running the Docker daemon, often root or a user in the docker group) might not have permission to traverse the parent directories leading up to it. This can manifest as the source path "not existing" to the Docker daemon, even if your user can see it.
Diagnosis:
Check the permissions of each directory in the path leading up to your source directory. For example, if your path is /mnt/data/projects/my-app/logs, check permissions for /, /mnt, /mnt/data, /mnt/data/projects, and /mnt/data/projects/my-app. You can use ls -ld /path/to/directory for each. Ensure the Docker user has execute (x) permissions on all parent directories to traverse them.
Fix: Grant execute permissions to the necessary directories for the user running Docker. If the Docker daemon runs as root, you might need to grant them more broadly (use with caution):
chmod +x /path/to/parent/directory
If you’re using a specific user that runs Docker, ensure that user is in the docker group and has permissions.
Why it works: The Docker daemon can now navigate through the directory tree to reach the specified source path.
5. Docker Desktop on macOS/Windows: Incorrect Path Syntax or Location
On macOS and Windows, Docker Desktop uses a virtual machine. Bind mounts are typically mapped from specific directories that you’ve allowed Docker to access. If the path is outside these allowed locations, or if the path syntax is incorrect for the host OS, it can cause this error.
Diagnosis: For Docker Desktop:
- Check Docker Desktop’s "Resources > File Sharing" settings to ensure the parent directory of your source path is listed.
- Verify the path syntax is correct for your host OS. For example, on Windows,
C:\Users\Me\datais correct, not/c/Users/Me/dataunless you’re using specific shell configurations.
Fix:
- Add the necessary directory to Docker Desktop’s File Sharing settings.
- Correct the path syntax to match your host OS. For instance, on Windows, if your
docker runcommand uses/c/Users/Me/data, change it toc:/Users/Me/dataor//c/Users/Me/data.
Why it works: Docker Desktop can now access the specified file system location on your host machine.
6. Docker Volume vs. Bind Mount Confusion
Sometimes, users intend to use a Docker-managed volume but incorrectly try to bind mount a path that doesn’t exist, expecting Docker to create it. Docker will create the target directory inside the container if it doesn’t exist, but it will not create the source directory on the host for bind mounts.
Diagnosis:
Review your -v or --mount flag. If the path on the host side (the part before the colon) is intended to be managed by Docker, you might be looking for a volume.
Fix: If you want Docker to manage the volume (creating it if it doesn’t exist, and storing it in Docker’s managed volume area), omit the host path and just provide the container path:
docker run -v /app/data your_image # This creates/uses a Docker volume named '/app/data'
Or, explicitly name the volume:
docker run -v my-app-data:/app/data your_image
Then, you can inspect its location with docker volume inspect my-app-data.
Why it works: This tells Docker to use its own volume management system, which handles creation and storage automatically.
Once you’ve fixed the bind mount source path issue, the next error you might encounter is related to permissions inside the container for the mounted volume.