How to Create an NFS Share: A Practical Guide for Linux Administrators
Network File System (NFS) is a classic solution for sharing files across Linux, Unix, and even mixed environments. Whether you’re building a collaborative workspace, provisioning shared storage for a cluster, or simply enabling easy access to media and project files, knowing how to create an NFS share is a valuable skill. This guide walks you through the essential concepts and a safe, reliable approach to create NFS share on a Linux server.
What is an NFS share?
An NFS share refers to a directory on a server that is exported to clients so they can mount it over the network. Once mounted, clients can read and write (depending on permissions) as if the files were on their own local disks. NFS is versioned, with NFSv4 offering improvements in performance and security, but many environments still rely on older versions for compatibility.
Prerequisites
- A Linux server with network access. Popular choices include Ubuntu, Debian, CentOS, and RHEL.
- Root or sudo privileges to install packages, modify exports, and restart services.
- The directory you plan to export, for example
/srv/nfs/share, with appropriate permissions for intended clients. - Firewall rules that allow NFS traffic, typically TCP/UDP ports 111 (portmapper) and 2049 (NFS), plus any high-numbered ports used by your distro’s RPC services.
Choosing the NFS version and export options
For most environments, NFSv4 is recommended because it consolidates the authentication model and is often easier to manage across subnets. If you need broad compatibility with older clients, you may support NFSv3 as well. When you configure the export, you’ll specify access control and performance options. A common starting point is to restrict access to your local subnet and use read-write permissions with careful security options (such as root_squash or all_squash depending on your trust model).
Step-by-step: Create NFS share
-
Install NFS server software. On Debian/Ubuntu, run:
sudo apt update; sudo apt install nfs-kernel-serverOn RHEL/CentOS, install and enable the NFS utilities:
sudo yum install nfs-utilssudo systemctl enable --now nfs-server -
Create the directory to share and set initial permissions. For example:
sudo mkdir -p /srv/nfs/sharesudo chown -R nobody:nogroup /srv/nfs/sharesudo chmod 755 /srv/nfs/share -
Edit the exports file to define the share and access rules. A typical entry for a private network could be:
/srv/nfs/share 192.168.1.0/24(rw,sync,no_subtree_check)For NFSv4 with a pseudo-root, you might export the directory differently, but the concept remains: you specify which hosts can access which paths and with what permissions.
-
Apply the export configurations so clients can see the new share:
sudo exportfs -asudo exportfs -v -
Start or restart the NFS service to finalize creating NFS share:
sudo systemctl enable --now nfs-serversudo systemctl restart nfs-kernel-server -
Open necessary firewall ports and test connectivity. For UFW users:
sudo ufw allow from 192.168.1.0/24 to any port nfsOr, at a minimum, allow the main NFS port 2049 and the portmapper (111):
sudo ufw allow 2049sudo ufw allow 111 -
Mount the share on a client to verify the setup. On a Linux client:
sudo mount -t nfs 192.168.1.10:/srv/nfs/share /mntTo make the mount persistent across reboots, add:
192.168.1.10:/srv/nfs/share /mnt nfs defaults,_netdev 0 0 -
Verify the exported shares from the server side:
showmount -e 192.168.1.10exportfs -v
Security and best practices
- Restrict access by IP or subnet. The
exportsline should specify hosts or subnets that are trusted to access the share. - Use appropriate export options.
rwenables read/write access;rocan be used for read-only shares. Considerroot_squashto prevent root users on clients from having root access to the server files. - Prefer NFSv4 or a modern configuration to take advantage of improved security features and simplified restore operations.
- Secure the network path with firewalls, and mount options like
noexecornosuidif appropriate for your environment. - Coordinate with your identity and authentication strategy. NFS relies on the server’s user IDs; ensure user mappings align across client systems.
- Consider using Kerberos (sec=krb5) for strong authentication in larger deployments, especially in mixed environments.
Troubleshooting tips
- Check the NFS service status and logs. On systemd systems:
systemctl status nfs-serverandjournalctl -u nfs-server. - Verify the exports on the server:
exportfs -vand make sure the path and options are correct. - Test client connectivity with ping and simple file operations, then inspect client-side logs for permission errors.
- On the client, use
showmount -e SERVER_IPto confirm what the server exports, and ensure the client IP is allowed by the export rules. - If mounting fails due to permissions, review both the filesystem permissions and the NFS export options, including
root_squashandno_subtree_check.
Common mistakes to avoid
- Exposing shares to an open network without restrictions on the export line.
- Using overly permissive permission sets (e.g.,
rw,rw,syncwith wide-open host lists) without proper security controls. - Neglecting to restart or re-load export configurations after editing /etc/exports.
- Overlooking firewall or SELinux contexts that block NFS traffic on either the server or client.
Conclusion
Creating an NFS share is a reliable way to centralize data access across a network, provided you design the export rules with security and performance in mind. By following the steps above, you can create NFS share that is straightforward to manage, scalable, and compatible with a wide range of Linux clients. Remember to test in a controlled environment before rolling changes into production, and regularly review export configurations and firewall rules to keep your file-sharing setup secure and efficient.