Linux NFS Howto
02/02/2004, by Adam Haeder

This is specific to RedHat, but most other Linux distributions follow the
same pattern.

An NFS server on linux requires 3 services to be running in order to share
files:
/etc/rc.d/init.d/portmap
/etc/rc.d/init.d/nfslock
/etc/rc.d/init.d/nfs

You can start/stop/restart these services by issues the above lines with
the corresponding arguments: start, stop or restart. You can also use the
shortcut 'service' command, as in:

# service portmap start

You need to ensure that these 3 services start up when the system does.
First, verify the default runlevel of the computer. Check the line in
/etc/inittab that starts with "id:". The next number will be the default
runlevel (usually 3 for non-gui, 5 for gui). You can manage the startup
scripts manually by creating symlinks in the corresponding /etc/rc.d/rcX.d
directory (where X is the default runlevel) or you can use redhat's
"chkconfig" command. Assuming the default runlevel is 3, these 3 commands
will ensure that the services necessary for an nfs server start at boot
time (these all must run as root):

# chkconfig --level 3 portmap on
# chkconfig --level 3 nfslock on
# chkconfig --level 3 nfs on

Now either reboot the box or issue these commands to start the nfs server:

# service nfs stop
# service nfslock stop
# service portmap stop
# service portmap start
# service nfslock start
# service nfs start

Order is important. Portmap must start first, followed by nfslock,
followed by nfs.

The file that defines what directories are shared is /etc/exports. 'man
exports' will give you the full overview of all options available for this
file. Here is an example line:

/public *(rw,no_root_squash)

This says share the folder /public, allow any IP access, give read/write
access, and allow the root user to connect as root.

The * wildcard can be a list or range of IP addresses. For example, if we
wanted to restrict this access to the 192.168.1.0/24 Class C subnet, the
line would look like this:

/public 192.168.1.0/255.255.255.0(rw,no_root_squash)

rw means read/write. no_root_squash is a setting that allows nfs clients
to connect as root. Without this setting, the root user on clients that
connect has the permissions of the user 'nfsnobody', uid 65534.

Anytime you make any changes to the /etc/exports file, run the command:

# exportfs -avr

on the server to update the nfs server.

On to the nfs client:
On the client, you need the 'portmap' and 'nfslock' services running.
Follow the instructions above to ensure that these 2 services start with
the default runlevel. Once they are running, you can mount a directory on
the nfs server. If the server ip is 192.168.1.1 and the share name is
public, you can do this on a client:

# mkdir /mnt/public
# mount 192.168.1.1:/public /mnt/public

You should get a prompt back. A 'mount' command should show you that the
nfs share is mounted, and you should be able to cd to this directory and
view the contents.

A couple of things to keep in mind with NFS: permissions are handled by
UID. It is very beneficial to ensure that a user on the client has the
same UID on the server. Otherwise the permissions will just confuse you.
If you are just using root, and using the no_root_squash option on every
mount, you don't have to worry about this.

Security: NFS should stand for No F**king Security. It's all IP based, so
if anyone can spoof an IP, they can mount on of your shares. NEVER do NFS
over an untrusted network (like the internet) and ALWAYS restrict your
shares to at least your local subnet.

There are 2 kinds of nfs mounts : soft mounts and hard mounts. With a soft
mount, if the server goes away (reboot/lost network/whatever) the client
can gracefully close the connection, unmount the share and continue on.
However, in order for the client to maintain this ability, it has to do
more caching of the reads and writes, so performace is lower and it's
possible to lose data if the server goes away unexpectedly.
A hard mount means that the client never gives up trying to hit the
server. Ever. Eventually the load on the client will be so high due to
backed up i/o requests, you'll have to reboot it. Not all that good, but
hard mounts don't have the caching overhead soft mounts do, so you have
less chance of losing data.
I always use hard mounts, but then specify the 'intr' option on the mount,
so I can unmount it manually if the server goes away (see example below).

Troubleshooting:
As with most things in linux, watch the log files. If you get an error on
the client when trying to mount a share, look at /var/log/messages on the
server. If you get an error like "RPC: program not registered" that means
that the portmap service isn't running on one of the machines. Verify all
the processes are running and try again.

Examples:
Here are some examples from one of my production linux nfs servers. On the
server, a line from /etc/exports:

/aim/exports/clink 192.168.23.0/255.255.255.0(rw,no_root_squash,async,wdelay)

Please see the manpage on exports for explanations of some of these
options. Here is the corresponding /etc/fstab entry on a client that
mounts this share (all on one line):

192.168.23.10:/aim/exports/clink       /aim/imports/clink nfs
rsize=8192,wsize=8192,timeo=20,retrans=6,async,rw,noatime,intr 0 0

You might want to experiment with rsize and wsize parameters to get that
last bit of performance. With this line in /etc/fstab, the mount is
remounted at boot. I can also issue the command 'mount -t nfs -a' to mount
all nfs entries in /etc/fstab with the corresponding options.