How to Set Up an NFS Share for Linux Workstations and Your NAS
A Network File System (NFS) share lets a Linux workstation access folders hosted on a NAS as though they were local directories. It is a practical choice for shared project files, media libraries, virtual machine images and centralised backups, particularly when several Ubuntu, Debian, Fedora or other Linux computers use the same storage.
The process is straightforward, but reliable results depend on more than switching on NFS. NAS permissions, Linux user IDs, firewall rules, network addressing and mount options all affect how safely and consistently files are accessed. The steps below apply broadly to Synology and QNAP systems, with minor differences in menu names and terminology.
Check The Network And NAS Requirements
Start by confirming that the NAS and Linux workstation are connected to the same trusted local network. A wired Ethernet connection is preferable for large transfers, especially when copying video or virtual machine data. Wi-Fi can work for ordinary documents, though congestion on an NBN home network may make performance inconsistent.
Give the NAS a fixed DHCP lease in the router or configure a suitable static address. For example, a NAS might use 192.168.1.20, while a workstation receives 192.168.1.50. A reserved address is usually easier to manage than manually configuring several devices. Test connectivity with:
ping 192.168.1.20
Before creating the share, review the NAS model, available storage and RAID arrangement. The NAS buying guide can help compare Synology and QNAP hardware, including systems with SSD caching, faster network ports and features useful for Linux workloads.
NFS is designed for trusted networks, not direct exposure to the internet. Do not forward NFS ports from an Australian home or office router to the public internet. Remote users should connect through a properly configured VPN, such as WireGuard or a business firewall service.
Enable NFS On The NAS
On a Synology NAS, open Control Panel, choose File Services, enable NFS and apply the settings. On a QNAP device, NFS support is generally found under Network & File Services or a similar section. The exact location varies between QTS, QuTS hero and DSM releases, but the option is usually labelled NFS service or Enable NFS.
Create a shared folder for the data. A clear name such as linux-data, projects or media makes administration easier. Avoid sharing the entire volume unless there is a strong reason to do so. A narrower export limits accidental access and makes backup policies easier to understand.
Edit the NFS permissions for the shared folder and add the workstation’s IP address or subnet. For a single workstation, use an address such as 192.168.1.50. For a trusted home LAN, a subnet such as 192.168.1.0/24 may be convenient, although it grants access to every device in that range.
Use read/write access only where it is required. Enable root squashing if the NAS offers that option, as it prevents the Linux root account from automatically gaining NAS administrator-level access. Avoid options such as no_root_squash unless you fully understand the security implications.
Configure Permissions And User Identity
NFS permissions are based heavily on numeric user and group IDs rather than simply matching usernames. A Linux account called alex with UID 1000 may not correspond to a NAS account called alex if that account has a different numeric ID. The result can be permission errors or files appearing to belong to an unexpected user.
For a simple household setup, create a NAS user with a matching UID and group ID if the NAS permits this level of administration. Another approach is to use a shared group and set the exported directory’s group ownership appropriately. On the workstation, inspect the current identity with:
id
Check the NAS shared-folder permissions as well as the NFS host access rules. Both layers must allow the required operation. A user may be allowed to connect through NFS but still receive “Permission denied” when opening or creating files because the underlying shared-folder ACL blocks access.
Separate personal files from collaborative data where possible. For a small office in Sydney, Melbourne or Brisbane, a dedicated project share with group access is usually safer than allowing every workstation to write across the entire NAS. Keep sensitive records restricted, especially where customer, employee or health information is involved. Australian organisations may also have obligations under the Privacy Act 1988 and the Australian Privacy Principles.
Install NFS Tools On Linux
Install the client package on the workstation. Ubuntu and Debian-based systems use nfs-common:
sudo apt update
sudo apt install nfs-common
On Fedora, Rocky Linux and other Red Hat-based distributions, install the NFS utilities package:
sudo dnf install nfs-utils
You can discover exports offered by the NAS with:
showmount -e 192.168.1.20
Some NFSv4 servers do not display exports through showmount, so an empty result does not always prove that the share is unavailable. You can also inspect the NAS documentation or test a direct mount.
Create a local mount point:
sudo mkdir -p /mnt/nas-projects
Mount the share manually before editing the boot configuration. A common NFSv4 command is:
sudo mount -t nfs4 192.168.1.20:/volume1/linux-data /mnt/nas-projects
QNAP exports may use a path such as /share/linux-data, while Synology commonly uses /volume1/share-name. Use the export path shown by the NAS rather than copying an example blindly. Confirm the result with:
mount | grep nas-projects
df -h /mnt/nas-projects
Make The Mount Persistent
A manual mount disappears after a reboot. To reconnect automatically, add an entry to /etc/fstab:
192.168.1.20:/volume1/linux-data /mnt/nas-projects nfs4 _netdev, x-systemd.automount,noatime 0 0
Remove the space after the comma if copying the line; the correctly formatted version is:
192.168.1.20:/volume1/linux-data /mnt/nas-projects nfs4 _netdev,x-systemd.automount,noatime 0 0
The _netdev option tells Linux that the mount requires a network connection. x-systemd.automount delays the connection until the directory is accessed, which can prevent boot delays when the NAS is offline. noatime reduces metadata writes, although it is optional and may not suit every application.
Test the file before rebooting:
sudo mount -a
If the command returns without an error, inspect the mount and create a harmless test file:
touch /mnt/nas-projects/test-file
ls -l /mnt/nas-projects
rm /mnt/nas-projects/test-file
For a laptop that regularly leaves the house, automounting is particularly useful. It avoids making startup dependent on the NAS being present, whether the computer is used at home in Perth or taken to a client site in Adelaide.
Secure And Troubleshoot The Connection
Use NFSv4 where possible because it has a cleaner protocol design and can simplify firewall management. If the NAS and client support Kerberos, NFSv4 with authenticated encryption offers stronger identity protection than a basic IP-based export. Many home users, however, rely on a trusted LAN, strong NAS administrator credentials and a separate guest network for untrusted devices.
A Linux firewall may need to allow NFS traffic on the local network. With UFW, rules should be limited to the trusted subnet rather than opened globally. For example:
sudo ufw allow from 192.168.1.0/24 to any port 2049 proto tcp
The exact ports and protocol depend on the NFS version and NAS configuration. Check firewall logs if a mount hangs or reports a timeout. Also verify that the NAS firewall allows the workstation address.
Common errors have predictable causes. “No such file or directory” usually indicates an incorrect export path. “Permission denied” points to NAS permissions, UID mismatches or root squashing. A timeout often indicates an incorrect IP address, firewall rule or inactive NFS service. If files are owned by unfamiliar numeric IDs, compare id output on the workstation with the NAS account and group IDs.
NFS access is not a backup. A deleted file can disappear from the mounted share immediately, and ransomware running on an authorised workstation may reach writable NAS folders. Use NAS snapshots where available, maintain a separate backup copy, and test restoration. For Australian households and small businesses, an external USB backup stored separately from the NAS can provide useful protection during hardware failure, theft or a local power event.
Compare Useful Mounting Choices
| Use case | Recommended approach | Main benefit | Important caution |
|---|---|---|---|
| Single trusted Linux workstation | NFSv4 with a fixed workstation IP | Simple administration and good performance | Keep the export limited to that IP |
| Several home Linux devices | NFSv4 using a trusted subnet | Convenient shared access | Every device on the subnet may connect |
| Mobile laptop | x-systemd.automount and _netdev |
Avoids boot failures when away from home | Access depends on the NAS being reachable |
| Shared office project files | Group-based NAS permissions and matching IDs | Consistent ownership between users | Review access when staff change |
| Sensitive business records | NFS through a protected VLAN or VPN | Better network separation | Requires more firewall and identity management |
| Large media or VM workloads | Wired Ethernet, fast NAS storage and careful testing | Higher sustained transfer rates | Wi-Fi and slow disks can become bottlenecks |
After the first successful mount, document the NAS address, export path, permissions model and backup schedule. Store that information in the administrator’s password manager or internal documentation rather than relying on memory. Review the arrangement when replacing a router, changing the LAN subnet or upgrading the NAS.
Use this setup as a controlled part of your storage system: keep exports narrow, match Linux and NAS identities, test recovery, and monitor available capacity. Configure the NFS client on one workstation first, verify read and write behaviour, then roll out the same pattern to other Linux machines with host-specific permissions.