NFS storage for containers

Using NFS storage for containers is common when you want shared persistent storage across multiple nodes or multiple containers. It can work well, but there are a few important tradeoffs.

Good use cases

• Shared volumes for app replicas
• Persistent data that needs to survive container restarts
• Centralized storage for logs, uploads, media, or backups
• Kubernetes / Docker Swarm workloads needing the same data on different hosts

Pros

• Easy to set up
• Shared across hosts
• Cheaper and simpler than many distributed storage systems
• Good for read-heavy or moderately shared data

Cons / risks

• Performance can be slower than local disks
• Latency-sensitive apps may suffer
• File locking and concurrent writes can be tricky
• If the NFS server goes down, storage becomes unavailable
• Some containerized databases do not perform well on NFS

Important considerations

• Use NFSv4 if possible
• Ensure proper UID/GID mapping so container permissions work correctly
• Set appropriate mount options like:
  • hard
  • noatime
  • nfsvers=4
• Avoid using NFS for high-write databases unless the database vendor supports it
• Test locking behavior if multiple containers write to the same files

Typical setup

• Export a directory from an NFS server
• Mount it on each container host
• Bind-mount it into the container, or use the orchestrator’s volume driver

Example Docker volume

docker volume create \
  --driver local \
  --opt type=nfs \
  --opt o=addr=10.0.0.10,nfsvers=4,rw \
  --opt device=:/exports/appdata \
  appdata_nfs

Recommendation

NFS is best for:

• shared app content
• config files
• media/uploads
• backups

Avoid it for:

• high-performance databases
• workloads requiring low latency or heavy concurrent writes

If you want, I can also give you:

1. a Docker Compose NFS example,
2. a Kubernetes PersistentVolume NFS example, or
3. guidance on whether NFS is suitable for your specific container app.