How to Share Files with NFS in Linux

I covered how to export a file system on the NFS server side. But exporting a directory is only half the story — the real value of NFS comes from client machines mounting that export and accessing the shared files as if they were local. This article focuses on the complete, practical process of sharing files with NFS from both the server and client perspective, with an emphasis on real-world usage, mounting strategies, and troubleshooting.

Table of Contents

1. Recap: What Is NFS File Sharing?
2. The Complete NFS Sharing Workflow
3. Server-Side Quick Setup
4. Client-Side: Installing NFS Utilities
5. Manually Mounting an NFS Share
6. Making the Mount Persistent with /etc/fstab
7. Auto-Mounting with autofs
8. Verifying and Testing File Sharing
9. Permissions and User Mapping Challenges
10. Real-World Example: Shared Team Directory
11. Cisco/Network Considerations for Multi-Site Sharing
12. Python Example: Automating Mount Verification
13. Comparison Table: Mounting Methods
14. Best Practices
15. Troubleshooting Common Issues
16. Conclusion

1. Recap: What Is NFS File Sharing?

NFS (Network File System) allows one Linux machine (the server) to make a directory available over the network, and other machines (clients) to mount that directory into their own file system tree. Once mounted, users on the client machine can read, write, create, and delete files in that shared directory exactly as if it were a local folder — all changes are instantly reflected for every other client with the same directory mounted.

2. The Complete NFS Sharing Workflow

graph LR
    A[1. Server: Install nfs-kernel-server] --> B[2. Server: Create shared directory]
    B --> C[3. Server: Add entry to /etc/exports]
    C --> D[4. Server: Run exportfs -ra]
    D --> E[5. Client: Install nfs-common]
    E --> F[6. Client: Create mount point directory]
    F --> G[7. Client: Mount the NFS share]
    G --> H[8. Users on client read/write files]

This diagram represents the complete end-to-end process — from setting up the server export (covered in the previous article) through to actually mounting and using the share on a client machine, which is our focus here.

3. Server-Side Quick Setup

For completeness, here’s a condensed version of the server-side steps (covered in detail in the previous article):

sudo apt update
sudo apt install nfs-kernel-server -y
sudo mkdir -p /srv/nfs/teamshare
sudo chown nobody:nogroup /srv/nfs/teamshare
sudo chmod 2775 /srv/nfs/teamshare
echo "/srv/nfs/teamshare  192.168.1.0/24(rw,sync,no_subtree_check)" | sudo tee -a /etc/exports
sudo exportfs -ra
sudo systemctl enable --now nfs-server

sudo apt update
sudo apt install nfs-kernel-server -y
sudo mkdir -p /srv/nfs/teamshare
sudo chown nobody:nogroup /srv/nfs/teamshare
sudo chmod 2775 /srv/nfs/teamshare
echo "/srv/nfs/teamshare  192.168.1.0/24(rw,sync,no_subtree_check)" | sudo tee -a /etc/exports
sudo exportfs -ra
sudo systemctl enable --now nfs-server

4. Client-Side: Installing NFS Utilities

On the client machine, you need the NFS client package, which is separate from the server package.

On Ubuntu/Debian:

sudo apt update
sudo apt install nfs-common -y

sudo apt update
sudo apt install nfs-common -y

On CentOS/RHEL/Fedora:

sudo dnf install nfs-utils -y

sudo dnf install nfs-utils -y

5. Manually Mounting an NFS Share

Step 1: Create a local mount point (an empty directory that will act as the access point).

sudo mkdir -p /mnt/teamshare

sudo mkdir -p /mnt/teamshare

Step 2: Mount the remote NFS export.

sudo mount -t nfs 192.168.1.100:/srv/nfs/teamshare /mnt/teamshare

sudo mount -t nfs 192.168.1.100:/srv/nfs/teamshare /mnt/teamshare

Here, 192.168.1.100 is the NFS server’s IP address, /srv/nfs/teamshare is the exported directory on the server, and /mnt/teamshare is the local mount point on the client.

Step 3: Verify the mount was successful.

df -h | grep teamshare

df -h | grep teamshare

Sample output:

192.168.1.100:/srv/nfs/teamshare   50G   12G   38G   24%  /mnt/teamshare

192.168.1.100:/srv/nfs/teamshare   50G   12G   38G   24%  /mnt/teamshare

Step 4: Test file sharing by creating a file.

echo "Hello from client!" > /mnt/teamshare/test.txt
cat /mnt/teamshare/test.txt

echo "Hello from client!" > /mnt/teamshare/test.txt
cat /mnt/teamshare/test.txt

If another client also has this same share mounted, they will immediately see test.txt appear in their /mnt/teamshare directory too.

6. Making the Mount Persistent with /etc/fstab

A manual mount using the mount command will disappear after a reboot. To make it persistent, add an entry to /etc/fstab.

Edit the fstab file:

sudo nano /etc/fstab

sudo nano /etc/fstab

Add this line:

192.168.1.100:/srv/nfs/teamshare   /mnt/teamshare   nfs   defaults,_netdev   0   0

192.168.1.100:/srv/nfs/teamshare   /mnt/teamshare   nfs   defaults,_netdev   0   0

The _netdev option is important — it tells the system to wait until the network is up before attempting to mount, preventing boot failures.

Test the fstab entry without rebooting:

sudo mount -a

sudo mount -a

7. Auto-Mounting with autofs

For environments where you don’t want the NFS share mounted permanently (to save resources or avoid boot delays if the server is temporarily unreachable), autofs mounts the share on-demand when accessed, and automatically unmounts it after a period of inactivity.

Install autofs:

sudo apt install autofs -y

sudo apt install autofs -y

Configure the master map file:

echo "/mnt/auto  /etc/auto.nfs" | sudo tee -a /etc/auto.master

echo "/mnt/auto  /etc/auto.nfs" | sudo tee -a /etc/auto.master

Create the map file /etc/auto.nfs:

teamshare    -rw,sync    192.168.1.100:/srv/nfs/teamshare

teamshare    -rw,sync    192.168.1.100:/srv/nfs/teamshare

Restart autofs:

sudo systemctl restart autofs

sudo systemctl restart autofs

Now, accessing /mnt/auto/teamshare for the first time will automatically trigger the mount, and it will unmount itself after being idle.

8. Verifying and Testing File Sharing

Check active NFS mounts on a client:

mount | grep nfs

mount | grep nfs

View NFS statistics (read/write operations, retransmissions):

nfsstat -c

nfsstat -c

Check what a server is exporting from the client side, before mounting:

showmount -e 192.168.1.100

showmount -e 192.168.1.100

Sample output:

Export list for 192.168.1.100:
/srv/nfs/teamshare 192.168.1.0/24

Export list for 192.168.1.100:
/srv/nfs/teamshare 192.168.1.0/24

9. Permissions and User Mapping Challenges

One of the trickiest parts of NFS file sharing is that user and group IDs (UID/GID) are shared by number, not by name, across client and server. If a user “alice” has UID 1001 on the server but UID 1005 on the client, file ownership will appear incorrect or inaccessible on one side.

Best solutions to this problem:

• Use a centralized identity system like LDAP or FreeIPA so UIDs/GIDs are consistent across all machines.
• Use NFSv4 with idmapping (/etc/idmapd.conf), which maps users by name rather than raw UID number, provided both server and client have matching domain settings.
• Manually align UIDs/GIDs when creating users on server and client machines in smaller environments.

Example /etc/idmapd.conf domain setting (must match on server and client):

[General]
Domain = example.com

[General]
Domain = example.com

10. Real-World Example: Shared Team Directory

A small software development team has five developers working from five different Linux workstations. Instead of using Git alone for everything (some large binary assets aren’t well-suited to version control), the team sets up a shared NFS directory for design assets:

• Server: fileserver.internal exports /srv/nfs/design-assets with rw access to the 192.168.1.0/24 subnet.
• Clients: Each developer’s workstation mounts this at /mnt/design-assets via /etc/fstab.
• Result: Any designer or developer can drop a new asset into the shared folder, and it’s instantly visible and editable by the rest of the team — no manual file transfers, no version conflicts on binary assets.

graph TD
    S[File Server: /srv/nfs/design-assets] --> C1[Developer 1: /mnt/design-assets]
    S --> C2[Developer 2: /mnt/design-assets]
    S --> C3[Developer 3: /mnt/design-assets]
    S --> C4[Developer 4: /mnt/design-assets]

11. Cisco/Network Considerations for Multi-Site Sharing

If clients and the NFS server are on different sites connected via a WAN (as discussed in our LAN/MAN/WAN article), NFS performance can degrade significantly due to latency, since NFS was originally designed for fast local networks. Considerations include:

• Avoid NFS over high-latency WAN links for interactive workloads; consider a caching file system or a sync tool (like rsync) instead.
• If NFS over WAN is unavoidable, use NFSv4.1+ with features like pNFS and increase read/write buffer sizes (rsize/wsize mount options) to reduce round trips.
• Configure QoS on Cisco routers/switches to prioritize NFS traffic (port 2049) across the WAN link, similar to the example shown in the previous article.

Example: increasing NFS buffer sizes on a slower link:

sudo mount -t nfs -o rsize=32768,wsize=32768,timeo=30 192.168.1.100:/srv/nfs/teamshare /mnt/teamshare

sudo mount -t nfs -o rsize=32768,wsize=32768,timeo=30 192.168.1.100:/srv/nfs/teamshare /mnt/teamshare

12. Python Example: Automating Mount Verification

This Python script checks whether a list of expected NFS mounts are actually active on a client machine — useful for automated health checks across a fleet of workstations.

import subprocess

expected_mounts = ["/mnt/teamshare", "/mnt/design-assets"]

def get_active_nfs_mounts():
    result = subprocess.run(["mount", "-t", "nfs,nfs4"], capture_output=True, text=True)
    return result.stdout

active_output = get_active_nfs_mounts()

for mount_point in expected_mounts:
    if mount_point in active_output:
        print(f"[OK]      {mount_point} is mounted.")
    else:
        print(f"[MISSING] {mount_point} is NOT mounted!")

import subprocess

expected_mounts = ["/mnt/teamshare", "/mnt/design-assets"]

def get_active_nfs_mounts():
    result = subprocess.run(["mount", "-t", "nfs,nfs4"], capture_output=True, text=True)
    return result.stdout

active_output = get_active_nfs_mounts()

for mount_point in expected_mounts:
    if mount_point in active_output:
        print(f"[OK]      {mount_point} is mounted.")
    else:
        print(f"[MISSING] {mount_point} is NOT mounted!")

Sample Output:

[OK]      /mnt/teamshare is mounted.
[MISSING] /mnt/design-assets is NOT mounted!

[OK]      /mnt/teamshare is mounted.
[MISSING] /mnt/design-assets is NOT mounted!

This kind of script can be scheduled with cron to alert administrators when an expected NFS mount has silently failed or been unmounted.

13. Comparison Table: Mounting Methods

14. Best Practices

• Always test mounts manually before adding them to /etc/fstab to avoid boot failures from typos.
• Use the _netdev option in /etc/fstab for any NFS mount to prevent boot delays or failures when the network isn’t ready yet.
• Standardize UID/GID mapping across your organization using LDAP, FreeIPA, or NFSv4 idmapping to avoid permission headaches.
• Use autofs for laptops or intermittently connected clients to avoid hanging boot processes when the NFS server is unreachable.
• Monitor NFS mounts with automated health checks (like the Python script above) to catch silent failures early.
• Avoid NFS for latency-sensitive workloads over WAN links; prefer it for LAN/CAN environments where it performs best.

15. Troubleshooting Common Issues

Quick fix for a stale NFS mount:

sudo umount -f /mnt/teamshare
sudo mount -a

sudo umount -f /mnt/teamshare
sudo mount -a

16. Advanced Concepts: NFS Locking and Concurrent Access

One of the trickiest aspects of sharing files with NFS is understanding how the protocol handles file locking when multiple clients attempt to read or write the same file simultaneously.

Network Lock Manager (NLM) in NFSv3

NFSv3 relies on a separate protocol called NLM (Network Lock Manager), running alongside NFS itself, to coordinate file locks between clients. This historically caused issues, since NLM state could be lost if the server rebooted, requiring clients to detect the failure and re-acquire locks — a process that isn’t always seamless.

Integrated Locking in NFSv4

NFSv4 solves this by integrating locking directly into the core protocol (no separate NLM service required), and by introducing the concept of a lease — a time-bounded grant of access that a client must periodically renew. If a client fails to renew its lease (for example, due to a crash or network partition), the server automatically releases the lock, preventing indefinite blocking of other clients.

sequenceDiagram
    participant C1 as Client 1
    participant Server as NFSv4 Server
    participant C2 as Client 2

    C1->>Server: Request lock on file.txt
    Server->>C1: Lock granted (lease started)
    C2->>Server: Request lock on file.txt
    Server->>C2: Lock denied - already held
    C1->>Server: Release lock / lease expires
    Server->>C2: Lock now available
    C2->>Server: Request lock on file.txt
    Server->>C2: Lock granted

Practical Implications for Shared Teams

When multiple users on different client machines are actively editing files in a shared NFS directory, application-level locking behavior matters as much as NFS’s own lock handling. Text editors and office applications that respect flock()/fcntl() locking will correctly prevent simultaneous conflicting writes, while poorly behaved applications that ignore locks entirely can still cause silent overwrites regardless of what NFS itself supports. This is why many teams pair NFS shared storage with version control (for code) or dedicated collaborative editing tools (for documents), rather than relying solely on file-level locking for critical concurrent work.

17. NFS Performance Tuning Tips

Beyond correct configuration, several tuning options can meaningfully improve NFS performance in demanding environments:

Example mount command combining several performance tuning options:

sudo mount -t nfs4 -o rsize=131072,wsize=131072,noatime,nconnect=4 192.168.1.100:/srv/nfs/teamshare /mnt/teamshare

sudo mount -t nfs4 -o rsize=131072,wsize=131072,noatime,nconnect=4 192.168.1.100:/srv/nfs/teamshare /mnt/teamshare

18. Frequently Asked Questions

Can Windows machines mount a Linux NFS export?

Yes, though it requires enabling the “NFS Client” feature on Windows (available in Windows 10/11 Pro and Enterprise editions, and Windows Server), or using third-party NFS client software. That said, in mixed Windows/Linux environments, many organizations prefer SMB/CIFS for Windows clients and reserve NFS specifically for Linux-to-Linux sharing, to avoid UID/GID mapping complications between the two very different permission models.

What happens if two clients edit the same file at the exact same time?

Without proper application-level locking, the last write to complete typically “wins,” silently overwriting the other client’s changes — a classic race condition. This is why collaborative editing of the same file by multiple simultaneous users is generally discouraged over plain NFS shares unless the applications involved implement robust locking or conflict resolution themselves.

Is it safe to run NFS shares over an untrusted public network?

Not without additional protection. Traditional NFS (sec=sys) trusts client IP addresses without strong authentication or encryption, making it unsuitable for use directly over the public internet. If NFS access is genuinely needed across untrusted networks, tunnel it through a VPN or use NFSv4 with Kerberos-based security (sec=krb5p) as covered in the previous article, rather than exposing NFS ports directly to the internet.

19. Scaling NFS Sharing Beyond a Single Server

As an organization grows, a single NFS server eventually becomes a bottleneck or a single point of failure. Several architectural approaches address this at scale:

• NFS with High Availability (HA) clustering: Tools like Pacemaker and Corosync on Linux allow two or more servers to share a virtual IP address and storage backend, so if the primary NFS server fails, a standby server takes over transparently, and clients experience only a brief pause rather than a full outage.
• Distributed file systems as an NFS alternative: For very large-scale deployments, systems like GlusterFS, CephFS, or Amazon EFS (in cloud environments) provide NFS-compatible interfaces backed by distributed, redundant storage across many physical nodes, rather than a single server.
• Read replicas for read-heavy workloads: In scenarios where most clients only need read access (like the raw footage example from the previous article), replicating data to multiple read-only NFS servers and distributing clients across them using DNS round-robin or a load balancer can significantly reduce load on any single machine.

graph TD
    VIP[Virtual IP: nfs.internal.company.local] --> Active[Active NFS Server]
    VIP -.->|Failover| Standby[Standby NFS Server]
    Active --- SharedStorage[(Shared/Replicated Storage)]
    Standby --- SharedStorage

20. Conclusion

Sharing files with NFS in Linux is a two-sided process: the server exports a directory with defined access rules, and clients mount that export locally, either manually, persistently via /etc/fstab, or on-demand via autofs. Once mounted, NFS creates a seamless, shared file system experience across multiple machines — ideal for team collaboration, centralized storage, and shared datasets within a LAN or CAN environment. Understanding UID/GID mapping and choosing the right mount strategy for your use case are the keys to a reliable, trouble-free NFS deployment.

Further Reading

• Linux mount Man Page
• Linux nfs Man Page
• Red Hat — Mounting NFS Shares
• Ubuntu Server Documentation — NFS Client Configuration
• Linux autofs Documentation
• IETF RFC 8881 — NFSv4.1 Protocol Specification