The NFS protocol is designed to be portable across different machines, operating systems, network architectures, and transport protocols. This portability is achieved through the use of Remote Procedure Call (RPC) primitives built on top of an eXternal Data Representation (XDR) (RFC1094 NFS v2).
NFS (Network File System) version 4 is a distributed file system protocol which owes heritage to NFS protocol versions 2 [RFC1094] and 3 [RFC1813]. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol.
[...]
The NFS version 4 protocol [...] retains the essential characteristics of previous versions: design for easy recovery, independent of transport protocols, operating systems and filesystems, simplicity, and good performance (RFC3010)
The NFS server runs the following daemons:
rpc.nfsd
rpc.mountd
These services are started with the
nfs sevice:
/etc/init.d/nfs start/stop/status/restart/reload
In addition rpc.statd is used to notify the client when the NFS service is unexpectedly interrupted, and rpc.lockd allows clients to lock files accessed on the server.
These services are started with the
nfslock service:
/etc/init.d/nfslock start/stop/status/restart
Programs using remote procedure calls (RPC) use specific program numbers
listed in /etc/rpc. When a RPC service is started it
will tell portmap which port number it is using as
well as its program number.
![]() | Note |
|---|---|
It is necessary for portmap to be running before starting any NFS service. |
RPC clients connect to the portmap
service, although it is possible to work around portmap
if the RPC program number is known.
Syntax:
directory <host>(<option1,option2,...>) <host>(<option1,...>)
Table 5.1. /etc/exports common options
| Option | Description |
|---|---|
ro | Read only. There is also the read-write option
rw |
no_root_squash | override the default
(root_squash) where
root is mapped to user
nobody |
async | the server writes to disk at predefined intervals (may cause data loss) |
sync | use sync rather than async when exporting a directory read-write |
Once a remote directory is mounted on the local client one would expect local users to access their files as if the directory was locally mounted. However this will only be the case if UIDs on both the local and remote systems correspond.

NFS is generally used in an environment where UIDs are common between the server and the clients.
It is possible, using anonuid
and anongid options to assign a unique
anonymous UID or GID per exported directory. Users mounting that share will
be given the rights of that anonymous ID on the server. For example,
everybody accessing the share below will inherit the right of the remote
user with UID=150 and GID=100
/share *(rw,anonuid=150,anongid=100)
By default the root user on the client system will be mapped to
the user nobody on the server.
This option is disabled in /etc/exports with the
no_root_squash option.

Finally, it is possible to map all users from any client to the
user nobody with the
all_squash option.
The portmap tool has been compiled with
libwrap giving us the option to
control access through /etc/hosts.allow and
/etc/hosts.deny.
strings `which portmap ` |grep hosts.allow
The exportfs command with no arguments will show all exported directories.
Table 5.2. exportfs options
-r | re-read /etc/exports and export all
directories listed |
-u | unexport all shares (until
exportfs -r is called) |
-a | applies to all exports |
-o | specify directories not listed in
/etc/exports |
The nfsstat displays statistics about NFS server and client activity. The information is read from two files:
/proc/net/rpc/nfs | contains information about NFS client activity |
/proc/net/rpc/nfsd | contains information about the NFS server |