How to Set Up NFS File Sharing on Linux: A Fast, Step-by-Step Guide
Get reliable shared storage across Linux systems fast with this clear, step-by-step NFS file sharing guide that walks admins and developers through architecture, setup, tuning, and security. By the end youll know which NFS version to choose, how to configure servers and clients, and what to consider for performance and hosting.
This guide walks you through setting up NFS (Network File System) file sharing on Linux with clear, practical steps and the technical background needed to deploy a reliable, performant solution. It’s written for site administrators, developers, and businesses that need shared storage across multiple Linux systems—either on-premises or in cloud VPS environments. By the end you’ll understand NFS architecture, common use cases, configuration details, performance tuning, security considerations, and recommendations for choosing a hosting plan such as a USA VPS at VPS.DO.
Introduction and core concepts
NFS is a protocol that allows a host (server) to share directories with one or more clients over a network. Clients mount exported directories and access files as if they were local. NFS is widely supported, compatible with POSIX file semantics (with some caveats across versions), and optimized for Unix/Linux environments.
Key NFS versions:
- NFSv3 — stateless server, widely supported, good performance for simple setups.
- NFSv4 — stateful, improved security and locking, built-in pseudo-filesystem, supports RPC over TCP and stronger authentication (including Kerberos).
- NFSv4.1/4.2 — adds session trunking, pNFS, and extended feature sets for higher performance and scalability.
When to use NFS — typical application scenarios
NFS is appropriate when multiple Linux systems need shared access to files. Common cases include:
- Web servers serving the same website content from multiple frontends.
- CI/CD runners and build nodes sharing caches and artifacts.
- Home directories and departmental shares in an organization.
- Container storage for orchestrated environments where host-based shared volumes are required.
NFS is not ideal for high-concurrency databases or latency-sensitive transactional workloads where block-level storage (iSCSI, locally attached SSDs) or specialized clustered filesystems are preferable.
Step-by-step setup: Server-side configuration
The following steps assume a Debian/Ubuntu or CentOS/RHEL-based Linux server. Adjust package manager commands accordingly.
Install NFS packages
On Debian/Ubuntu: sudo apt update && sudo apt install nfs-kernel-server
On CentOS/RHEL: sudo yum install nfs-utils && sudo systemctl enable –now nfs-server
Create and export a directory
Create the export directory and set permissions. Example:
- sudo mkdir -p /srv/nfs/shared
- sudo chown nobody:nogroup /srv/nfs/shared (or set a specific UID/GID to preserve ownership)
Edit /etc/exports to define exports and client access rules. Example entries:
- /srv/nfs/shared 10.0.0.0/24(rw,sync,no_subtree_check)
- /srv/nfs/project 192.168.1.10(rw,sync,root_squash)
Meaning of common export options:
- rw/ro — read-write or read-only.
- sync/async — sync forces writes to disk before replying; safer but slower. async can improve throughput.
- no_subtree_check — improves reliability when exporting subdirectories.
- root_squash — maps root on client to nobody for security.
Apply exports:
- sudo exportfs -ra
- sudo exportfs -v (to verify)
Ensure the NFS service is running:
- sudo systemctl enable –now nfs-server
- sudo systemctl status nfs-server
Firewall and RPC ports
NFS uses multiple RPC services. For NFSv4 the protocol consolidates on TCP port 2049, which simplifies firewall rules. For NFSv3 you may need to open additional ports (rpcbind, mountd, statd, lockd). Example for UFW allowing NFSv4:
- sudo ufw allow from 10.0.0.0/24 to any port 2049/tcp
For firewalld (CentOS/RHEL): sudo firewall-cmd –add-service=nfs –permanent && sudo firewall-cmd –reload
Client-side configuration and mounting
Install client packages
On Debian/Ubuntu: sudo apt install nfs-common
On CentOS/RHEL: sudo yum install nfs-utils
Mount manually
Create mount point and mount:
- sudo mkdir -p /mnt/shared
- sudo mount -t nfs4 server.example.com:/srv/nfs/shared /mnt/shared (NFSv4)
- or for NFSv3: sudo mount -t nfs server:/srv/nfs/shared /mnt/shared
Persist mounts in /etc/fstab:
- server.example.com:/srv/nfs/shared /mnt/shared nfs4 defaults,_netdev,auto 0 0
Recommended client mount options:
- rsize= and wsize= — control read/write buffer sizes (e.g., rsize=1048576,wsize=1048576 for modern kernels).
- noatime — reduce metadata writes.
- hard/soft — hard retries until server responds (recommended for critical files); soft can return errors on timeout.
- tcp — prefer TCP for reliability, especially across WAN.
Security considerations
NFS relies on client-side UID/GID mapping by default, which can be a security vector if clients impersonate users. Options to improve security include:
- Use root_squash to prevent root access from clients.
- Run NFS over a private network or VPN; restrict exports to specific IP ranges.
- For strong authentication and integrity/confidentiality, use NFSv4 with Kerberos (sec=krb5, krb5i, krb5p).
- Use transport-layer security (stunnel/SSH tunnels) if Kerberos is not available and you must traverse untrusted networks.
Performance tuning and best practices
Common levers to tune NFS performance:
- Use NFSv4 when possible: fewer RPC round-trips and consolidated ports improve throughput and firewall management.
- Tune rsize/wsize: larger values can reduce CPU and network overhead (but ensure network and server support it).
- Filesystem choices: choose a server filesystem optimized for small-file metadata if your workload is metadata-heavy (ext4, XFS, or btrfs depending on needs).
- Server hardware: use SSDs and adequate RAM for metadata caching; configure multiple NFS server threads (mountd/nfsd threads) to handle concurrency.
- Async vs sync: async may increase throughput for caches but risks data loss on crash. Use async for non-critical workloads and sync for critical data.
- Network tuning: enable jumbo frames on LANs if supported, and tune TCP window sizes for high-latency links.
Troubleshooting checklist
Quick commands and checks:
- sudo exportfs -v — check exported paths and options on server.
- showmount -e server — verify exported shares from a client.
- rpcinfo -p server — lists RPC services and ports.
- journalctl -u nfs-server — inspect server logs for errors.
- mount | grep nfs — list mounted NFS shares on client.
- Check permissions and UID/GID mismatches when seeing access denied or wrong owner behavior.
Advantages and comparison with alternatives
Advantages of NFS:
- Native Linux/Unix support and POSIX semantics for many operations.
- Relatively simple to set up for LAN environments, especially NFSv4.
- Efficient for shared read-heavy workloads, web content distribution, and home directories.
When to choose alternatives:
- For block-level access and raw database performance, use iSCSI or local SSDs.
- For multi-writer clustering across nodes with strong consistency, consider clustered filesystems (GFS2, OCFS2) or distributed systems like CephFS or GlusterFS.
- For Windows interoperability, SMB/CIFS may be more appropriate.
Capacity planning and hosting advice
When deploying NFS in production, consider:
- IOPS and throughput requirements — size server disks and network bandwidth accordingly.
- High availability — use replication, failover, or clustered storage to avoid single points of failure.
- Backup and snapshot strategies — NFS servers should be included in regular backup plans; consider filesystem snapshots for quick recovery.
If you plan to host NFS on cloud or VPS infrastructure, choose plans with predictable network performance and sufficient I/O. For example, VPS.DO offers USA VPS plans that can be suitable for hosting NFS servers for small to medium workloads; evaluate disk type (SSD), network capacity, and available memory when selecting a plan. More details: USA VPS at VPS.DO.
Summary
NFS is a mature, efficient solution for sharing files across Linux hosts when deployed with the right version, security model, and tuning. Start with NFSv4 on a private or trusted network, restrict exports by network and use root_squash for safety. Tune rsize/wsize, thread counts, and filesystem choices to match your workload. For sensitive environments requiring strong authentication, integrate NFSv4 with Kerberos. For production deployments on VPS, pick a provider and plan that offers robust I/O and networking—consider evaluating VPS.DO’s USA VPS options as part of your infrastructure selection process: https://vps.do/usa/.