Linux NFS General Setup Guide

The Network File System (NFS) was originally developed by Sun Microsystems in 1983, to allow a user on a client PC to access files over the network with as much ease as if accessing a local disk.

A unique aspect of NFS, which makes it appear seamless to the end-user, is that connecting to a NFS share does not require a password, and files on the server appear in every respect to be a users' own files. Security is enforced by limiting access to trusted hosts, and by using the standard Linux file system permissions. The UIDs and GIDs of users are mapped from the server to the client. Therefore, if a user on a client has the same UID and GID as a user on the server, they have access to files in the NFS share owned by that UID and GID. NFS is easy to grasp, which leads to quick and easy configuration. It is worthwhile to mention, that NFS does not use any encrypted communication, making it possible for data to be caught in transmission by a third-party. Also, improper management of users on a client can incorrectly give file access to the wrong user. However it is critical that the administrators of all allowed hosts are trusted.

In a general Linux scenario, in which one machine (the client) requires access to data stored on another machine (the NFS server) the general procedure for setting up the NFS environment is as follows:

1. The server runs NFS daemon processes (running by default as nfsd) in order to make its data generically available to clients.
2. The server administrator determines what to make available, exporting the names and parameters of directories (typically using the /etc/exports configuration file and the exportfs command).
3. The server security-administration ensures that it can recognize and approve validated clients.
4. The server network configuration ensures that appropriate clients can negotiate with it through any applicable firewall system.
5. The client machine requests access to exported data, typically by issuing a mount command.
6. If all goes well, users on the client machine can then view and interact with mounted filesystems on the server within the parameters permitted.

NFS shares are stored in the /etc/exports file, and are specified one per line. Each share can contain several hosts/options declarations. The general syntax is:

/share_path hosts_1(options) hosts_2(options) ... hosts_n(options)

For example:

/share *(ro,all_squash) 192.168.1.152(rw,root_squash)

(For more examples, see the exports man page).

To mount a NFS share on a client, add the share to the /etc/fstab file. The syntax is:

host:/share_path /local_mount_point nfs options dump fsck

For example:

server.openminds.local:/data /share nfs defaults 0 0

The hosts permitted to connect to a share can be specified in several ways (taken from the exports(5) man page):

• Single host - This is the most common format. You may specify a host either by an abbreviated name resolvable in DNS or the hosts file, the fully qualified domain name, or an IP address.

• Netgroups - NIS netgroups may be given as ‘@group’. Only the host part of each netgroups member is considered in checking for membership. Empty host parts or those containing a single dash (-) are ignored.

• Wildcards - Machine names may contain the wildcard characters * and ?. This can be used to make the exports file more compact; for instance, *.openminds.local matches all hosts in the domain openminds.local. As these characters also match the dots in a domain name, the given pattern will also match all hosts within any sub-domain of openminds.local (e.g. host.subdom.openminds.local).

• IP networks - You can also export directories to all hosts on an IP (sub-) network simultaneously. This is done by specifying an IP address and netmask as address/netmask where the netmask can be specified in dotted-decimal format, or as mask length (for example, either `/255.255.255.0' or `/24').
  N.B. Wildcard characters generally do not work on IP addresses, though they may work by accident when reverse DNS lookups fail.

There are many options for shares. Here are some of the most common:

• root_squash - Maps the root user to the nobody user. This prevents a user logged in as root on a client to gain root file access permissions on the server.
• no_root_squash - Does not map the root user to the nobody user. The root user on a client has the same rights as the root user on the server.
• all_squash - Maps all the UIDs and GIDs to the nobody user. This is useful if the share is to have anonymous access, much like an anonymous FTP server.
• anonuid, anongid - If root_squash and all_squash are used, the UIDs and GIDs are mapped to the specified UID and GID instead of the nobody user.
• ro - Forces all files on the share to be read-only. This is the default behavior.
• rw - Allows write access to the share.
• sync - Ensures data is written to disk before another request is serviced.

The NFS server is controlled with the /sbin/rcnfsserver script, and the client is controlled with the /sbin/rcnfs script. The major options are:

• start
• stop
• restart

For example, to start the server, execute:

# rcnfsserver start