🚨 Docker Error Guide: 'failed to mount local volume: no such file or directory' — Missing Bind Source

Overview

Docker fails to start a container when the source path for a local volume mount does not exist on the host. It appears on docker run, docker compose up, or docker start:

docker: Error response from daemon: failed to mount local volume: mount /data/myapp: no such file or directory

With a named volume that uses the local driver with a device option, the same message names the device path:

Error response from daemon: failed to mount local volume: mount /srv/nfs/myapp:/var/lib/docker/volumes/myapp/_data, flags: 0x1000: no such file or directory

The kernel returned ENOENT: the host path Docker was told to mount from does not exist. This is a source-path problem, not a permissions or disk issue.

Symptoms

• A container that uses a local volume with a device option refuses to start.
• docker compose up fails on a service whose volume device: path is missing.
• The volume exists in docker volume ls but mounting it fails.
• A bind-mount to an NFS/CIFS path fails because the export path is wrong or the share is unmounted.
• The error names a specific path after mount that does not exist on the host.

Common Root Causes

• Missing device path on a named local volume — a volume created with --opt device=/srv/nfs/myapp where that directory does not exist.
• NFS/CIFS share not mounted or wrong export path — the device points at a network path that is not currently available.
• Typo in the volume device option or Compose device: field.
• Directory deleted after the volume was created — the source existed at creation but was later removed.
• Wrong o= mount options for NFS (missing addr=, wrong nfsvers) so the mount target cannot resolve.
• Relative or non-absolute device path that Docker cannot resolve at mount time.

Diagnostic Workflow

First, inspect the failing volume to see the exact driver options and device path:

docker volume ls
docker volume inspect myapp

Look at the Options block — device, type, and o tell you what Docker will try to mount:

docker volume inspect myapp --format '{{json .Options}}'

Confirm whether that device path actually exists on the host:

ls -ld /srv/nfs/myapp
mount | grep /srv/nfs

If it is an NFS/CIFS volume, verify the share is reachable and mounted where expected:

showmount -e nfs.example.com
sudo mount -t nfs nfs.example.com:/exports/myapp /srv/nfs/myapp   # test manually

For a plain bind-mount, check the source you passed to -v:

docker run --rm -v /data/myapp:/app alpine ls /app

Example Root Cause Analysis

A Compose stack defines an NFS-backed named volume and the app container fails with failed to mount local volume: ... no such file or directory. Inspecting the volume shows what Docker tries to mount:

docker volume inspect stack_myapp --format '{{json .Options}}'
# {"device":":/exports/myapp","o":"addr=nfs.example.com,nfsvers=4","type":"nfs"}

The options look right, but testing the export reveals the real path on the server is /srv/exports/myapp, not /exports/myapp:

showmount -e nfs.example.com
# /srv/exports/myapp   10.0.0.0/24

The device path was wrong, so the kernel returned ENOENT. Correcting the Compose volume definition fixes it:

volumes:
  myapp:
    driver: local
    driver_opts:
      type: nfs
      o: "addr=nfs.example.com,nfsvers=4"
      device: ":/srv/exports/myapp"

Recreate the volume so the corrected option takes effect, then start the stack:

docker volume rm stack_myapp
docker compose up -d

For a simple bind-mount case, the fix is just creating the missing host directory before running: mkdir -p /data/myapp.

Prevention Best Practices

• Create host source directories (mkdir -p) before starting containers that bind-mount them, or let your provisioning step ensure they exist.
• Store NFS/CIFS export paths and mount options in version-controlled Compose files and validate them against showmount -e.
• Recreate named volumes after changing driver_opts; Docker does not update options on an existing volume.
• Use absolute paths for every device option and bind-mount source.
• Add a startup check that verifies required mount points exist before launching services.
• Monitor NFS/CIFS availability so a disappearing share is caught before it breaks container starts.

Quick Command Reference

# Inspect the volume's driver options and device path
docker volume inspect myapp --format '{{json .Options}}'

# Confirm the device path exists on the host
ls -ld /srv/nfs/myapp && mount | grep /srv/nfs

# Verify an NFS export path and options
showmount -e nfs.example.com

# Recreate a volume after fixing options
docker volume rm myapp && docker compose up -d

# Test a plain bind-mount source
docker run --rm -v /data/myapp:/app alpine ls /app

Conclusion

failed to mount local volume: no such file or directory means the source path Docker was told to mount does not exist — a missing bind-mount directory or a wrong device option on a named local volume. Inspect the volume’s options, confirm the path exists (creating it or fixing the NFS export path as needed), and recreate the volume after any option change. Ensuring source paths exist before container start prevents the error entirely. For more volume fixes, see the Docker guides.