How to fix Error response from daemon: error while mounting volume: NFS mount failed in Docker

DockerINTERMEDIATEMEDIUMUpdated Dec 1, 2025· 178 views

This error occurs when Docker cannot mount an NFS volume to a container. Common causes include incorrect NFS server configuration, missing NFS client utilities, network connectivity issues, or permission problems.

Quick fix

Fixes Error response from daemon: error while mounting volume: NFS mount failed

sudo apt-get update
sudo apt-get install nfs-common
  1. Verify NFS client is installed on the Docker host
  2. Test NFS connectivity from the Docker host
  3. Check firewall and network connectivity
  4. Verify NFS export configuration on the server
docker — error
sudo apt-get update
sudo apt-get install nfs-common
Error response from daemon: error while mounting volume: NFS mount failed

What this error means

When Docker attempts to mount an NFS (Network File System) volume into a container, it relies on the host system's NFS client to establish the connection to the remote NFS server. The "NFS mount failed" error indicates that this connection could not be established. NFS volumes in Docker are useful for sharing persistent data across multiple containers or hosts, particularly in clustered environments like Docker Swarm. However, unlike local bind mounts, NFS mounts require proper network configuration, server accessibility, and compatible mount options. The error can originate from various points in the NFS mounting chain: the Docker daemon failing to initiate the mount, the NFS client being unavailable or misconfigured, network issues preventing communication with the NFS server, or the NFS server rejecting the mount request due to export rules or permissions.

Typical symptoms

  • Container fails to start with 'error while mounting volume: NFS mount failed'
  • Docker Compose services hang during volume mounting phase
  • Error message includes 'mount.nfs: rpc.statd is not running' or similar RPC errors
  • Kubernetes pods fail with 'MountVolume.SetUp failed' for NFS persistent volumes
  • NFS mounts work directly on the host but fail inside Docker
  • Docker service or stack deployments fail at the volume mounting step
  • Connection refused or timeout errors when attempting NFS volume mounts

Common causes

  1. NFS client utilities are not installed on the Docker host
  2. NFS server is unreachable due to network issues or firewall rules
  3. Incorrect NFS server address or export path in volume configuration
  4. NFS server export permissions do not allow the Docker host
  5. Missing or incorrect NFS version specification in mount options
  6. The exported NFS directory does not exist on the server
  7. Root squash settings on NFS server prevent Docker from accessing files
  8. Stale file handles from previous mount attempts
  9. Docker Desktop VM lacks NFS client support (macOS/Windows)
  10. Firewall blocking NFS ports (2049, 111 for portmapper)

How to fix "Error response from daemon: error while mounting volume: NFS mount failed"

1Verify NFS client is installed on the Docker host

Docker relies on the host system's NFS client to mount NFS volumes. Install the NFS client utilities if they're missing:

On Debian/Ubuntu:

bash
sudo apt-get update
sudo apt-get install nfs-common

On RHEL/CentOS/Fedora:

bash
sudo yum install nfs-utils
# or on newer systems:
sudo dnf install nfs-utils

On Alpine (common in CI environments):

bash
apk add nfs-utils

Verify the installation:

bash
showmount --version
2Test NFS connectivity from the Docker host

Before debugging Docker, verify that NFS works at the host level:

bash
# List exports available from the NFS server
showmount -e <nfs-server-ip>

# Test manual mount
sudo mkdir -p /tmp/nfs-test
sudo mount -t nfs <nfs-server-ip>:/path/to/export /tmp/nfs-test

# Check if mount succeeded
df -h /tmp/nfs-test

# Clean up test mount
sudo umount /tmp/nfs-test

If the manual mount fails, the issue is with NFS configuration, not Docker. Common errors and their meanings:
- "Connection refused": NFS server not running or blocked by firewall
- "No route to host": Network connectivity issue
- "Access denied": Export rules don't permit this host

3Check firewall and network connectivity

Ensure the required ports are open between Docker host and NFS server:

Required NFS ports:
- TCP/UDP 2049 (NFS)
- TCP/UDP 111 (portmapper/rpcbind)

Test connectivity:

bash
# Check if NFS port is accessible
nc -zv <nfs-server-ip> 2049

# Check portmapper
nc -zv <nfs-server-ip> 111

# Test with rpcinfo
rpcinfo -p <nfs-server-ip>

On the NFS server (if you have access):

bash
# Check if NFS services are running
systemctl status nfs-server
systemctl status rpcbind

# Open firewall ports (firewalld)
sudo firewall-cmd --permanent --add-service=nfs
sudo firewall-cmd --permanent --add-service=mountd
sudo firewall-cmd --permanent --add-service=rpc-bind
sudo firewall-cmd --reload
4Verify NFS export configuration on the server

Check that the NFS server is exporting the correct path with appropriate permissions:

On the NFS server, check /etc/exports:

bash
cat /etc/exports

The export entry should include your Docker host's IP or subnet:

bash
/path/to/share 192.168.1.0/24(rw,sync,no_subtree_check)

Key options to check:
- rw or ro: Read-write or read-only access
- no_root_squash: Allows root access (needed for some Docker operations)
- no_subtree_check: Improves reliability

After modifying /etc/exports, reload:

bash
sudo exportfs -ra
5Correct Docker volume configuration syntax

Ensure your Docker NFS volume is configured correctly:

Using docker volume create:

bash
docker volume create --driver local \
  --opt type=nfs \
  --opt o=addr=192.168.1.100,nfsvers=4,rw \
  --opt device=:/path/to/export \
  my-nfs-volume

In docker-compose.yml:

yaml
version: '3.8'
services:
  app:
    image: myapp
    volumes:
      - nfs-data:/app/data

volumes:
  nfs-data:
    driver: local
    driver_opts:
      type: nfs
      o: "addr=192.168.1.100,nfsvers=4,rw,soft,nolock"
      device: ":/path/to/export"

Common mistakes:
- Missing colon before the path in device (should be :/path not /path)
- Using hostname instead of IP (can cause DNS resolution issues)
- Incorrect NFS version (try nfsvers=3 or nfsvers=4)

6Add helpful mount options for common issues

Add mount options to work around common NFS problems:

yaml
volumes:
  nfs-data:
    driver: local
    driver_opts:
      type: nfs
      o: "addr=192.168.1.100,nfsvers=4,rw,soft,timeo=180,nolock"
      device: ":/path/to/export"

Useful mount options:
- soft: Return an error if server is unreachable (instead of hanging indefinitely)
- timeo=180: Timeout in deciseconds (180 = 18 seconds)
- nolock: Disable file locking (helps with some NFS server configurations)
- nfsvers=3 or nfsvers=4: Force specific NFS version
- tcp: Force TCP protocol (more reliable than UDP)

For Docker for Windows connecting to Linux NFS server:
Add the hard and nolock options, and ensure the NFS server has insecure in the export options.

7Handle root squash permission issues

NFS servers often use "root squash" which maps root access to nobody/nogroup, causing permission issues for Docker:

Symptoms:
- "Permission denied" errors when Docker tries to initialize volume
- Container can read but not write to NFS mount

Option 1: Add no_root_squash to NFS export (security implications):

bash
# On NFS server, edit /etc/exports:
/path/to/share 192.168.1.0/24(rw,sync,no_root_squash,no_subtree_check)

sudo exportfs -ra

Option 2: Use nocopy option in Docker:

bash
docker run -v nfs-volume:/app/data:nocopy myimage

This prevents Docker from trying to copy files to the volume, avoiding permission issues during initialization.

Option 3: Ensure world-readable permissions:
On the NFS server, ensure the directory has appropriate permissions:

bash
chmod 755 /path/to/share
8Clear stale NFS mounts and Docker volumes

Stale NFS handles or cached Docker volumes can cause persistent mount failures:

Clear stale Docker volumes:

bash
# List all volumes
docker volume ls

# Remove the problematic volume (if not in use)
docker volume rm my-nfs-volume

# Recreate the volume
docker volume create --driver local \
  --opt type=nfs \
  --opt o=addr=192.168.1.100,nfsvers=4 \
  --opt device=:/path/to/export \
  my-nfs-volume

Clear stale NFS mounts on host:

bash
# Check for stale mounts
mount | grep nfs

# Force unmount stale entries
sudo umount -f /var/lib/docker/volumes/my-nfs-volume/_data

# If that fails, lazy unmount
sudo umount -l /var/lib/docker/volumes/my-nfs-volume/_data

Restart Docker daemon:

bash
sudo systemctl restart docker
9Handle Docker Desktop limitations (macOS/Windows)

Docker Desktop runs containers inside a VM, which has limited NFS support:

Docker Desktop for Mac:
- Recent versions have NFS client support, but it may require additional configuration
- If NFS mounts fail, check Docker Desktop settings for virtualization framework options
- Some users report success switching between "Apple Virtualization" and "QEMU"

Docker Desktop for Windows:
- WSL2 backend may have better NFS support than Hyper-V
- Ensure NFS server has insecure option in exports (for non-privileged ports)

Alternative approach - mount on host first:

bash
# Mount NFS to host directory
sudo mount -t nfs 192.168.1.100:/export /mnt/nfs-share

# Use bind mount in Docker
docker run -v /mnt/nfs-share:/app/data myimage

This bypasses Docker's NFS volume driver and uses a simple bind mount instead.

Advanced notes

NFS vs Docker overlay2 storage driver:
Do not use NFS as Docker's storage backend (data-root). The overlay2 filesystem requires ext4 or xfs with ftype=1, not NFS. NFS should only be used for volumes mounted into containers, not for storing Docker images and container layers.

Kubernetes NFS considerations:
When using NFS persistent volumes in Kubernetes on Docker Desktop, additional configuration may be required. The error "rpc.statd is not running" often indicates the Kubernetes node (Docker Desktop VM) lacks the NFS client. Some users have resolved this by using the NFS CSI driver instead of native NFS volumes.

Docker Swarm and NFS:
For Docker Swarm services, NFS volumes are mounted on each node where the service runs. Ensure all swarm nodes have NFS client installed and can reach the NFS server. Use the --mount flag syntax rather than -v for services.

NFSv4 vs NFSv3:
NFSv4 uses a single port (2049) and doesn't require portmapper, making it easier to configure through firewalls. NFSv3 requires additional ports for mountd and other services. If your environment allows, prefer NFSv4.

Debugging mount failures:
Enable verbose NFS output for detailed error information:

bash
# On the NFS client (Docker host)
rpcdebug -m nfs -s all
dmesg | tail -50

# After debugging, disable verbose logging
rpcdebug -m nfs -c all

Performance tuning:
For high-throughput NFS mounts, consider adjusting read/write buffer sizes:

yaml
o: "addr=192.168.1.100,nfsvers=4,rsize=65536,wsize=65536,hard,timeo=600"

Frequently asked questions

What does "Error response from daemon: error while mounting volume: NFS mount fai" mean?
When Docker attempts to mount an NFS (Network File System) volume into a container, it relies on the host system's NFS client to establish the connection to the remote NFS server. The "NFS mount failed" error indicates that this connection could not be established. NFS volumes in Docker are useful for sharing persistent data across multiple containers or hosts, particularly in clustered environments like Docker Swarm.
How do I fix "Error response from daemon: error while mounting volume: NFS mount fai"?
This error occurs when Docker cannot mount an NFS volume to a container. Common causes include incorrect NFS server configuration, missing NFS client utilities, network connectivity issues, or permission problems.
What causes "Error response from daemon: error while mounting volume: NFS mount fai"?
NFS client utilities are not installed on the Docker host NFS server is unreachable due to network issues or firewall rules Incorrect NFS server address or export path in volume configuration
Is the "Error response from daemon: error while mounting volume: NFS mount fai" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading