NFS

Network File System lets a client access a server export through the local filesystem namespace. The server controls exports and much of the access policy; the client controls where and when an authorized export is mounted.

Preparing the Client

Install the distribution's NFS client utilities, commonly packaged as nfs-common on Debian-family systems or nfs-utils on Red Hat-family systems. Confirm DNS or address reachability, allowed NFS versions, firewall policy, and the exact export path with the server administrator.

showmount -e SERVER can list exports provided through the older mount protocol, but it is not authoritative for every NFSv4-only server. A failed listing does not prove that no authorized NFSv4 export exists.

Mounting an Export

Create an empty, dedicated mount point and mount the approved export:

$ sudo mkdir -p /mnt/team
$ sudo mount -t nfs server.example.net:/srv/team /mnt/team

Specify a version only when policy or compatibility requires it, for example -o vers=4.2. Do not guess performance or security options. Confirm the resulting source, type, and options:

$ findmnt --target /mnt/team

Understanding Identity and Permissions

NFS access combines server export rules, protocol security, numeric identities or directory services, and filesystem permissions. Matching usernames displayed on two hosts do not guarantee matching numeric IDs. Traditional AUTH_SYS sends client-provided numeric identities and depends heavily on trusted client and network controls; stronger environments can use Kerberos security modes when configured end to end.

The server commonly maps remote root to an unprivileged identity through root squashing. Do not disable that protection merely to fix a permission error; inspect IDs, directory ownership, export policy, and the intended security model.

Automating Network Mounts

A plain boot-time /etc/fstab mount can delay startup when networking or the server is unavailable. Depending on the host, use autofs for on-demand maps or systemd mount options such as _netdev,nofail,x-systemd.automount after testing their exact semantics:

server.example.net:/srv/team /mnt/team nfs4 rw,_netdev,nofail,x-systemd.automount 0 0

Before editing fstab, preserve recovery access and validate with a non-destructive parser or a controlled mount test. An automount improves availability behavior but does not fix authorization, DNS, or server outages.

Unmounting and Verification

Before unmounting, stop or coordinate processes using the share and flush application work. Then unmount the mount point and verify it is gone:

$ sudo umount /mnt/team
$ findmnt --target /mnt/team

A forced or lazy unmount can hide active references and risk application errors; reserve such options for a diagnosed failure with an explicit recovery plan.

Summary

You can now operate an NFS client mount with explicit identity and availability assumptions.

1. Confirm client tools, export path, protocol, and network policy.
2. Mount to a dedicated path and verify the effective source and options.
3. Diagnose permissions through identity and export policy.
4. Use tested on-demand mounting when boot availability matters.
5. Coordinate users, unmount normally, and verify removal.