General:
Network File System (NFS):
http://nfs.sourceforge.net/nfs-howto/server.html
An NFS system involves both a server and a client. The use of an NFS system allows
a client machine to mount a network server's filesystem as though it were it's a
local filesystem. According to the permissions the server grants the client, users
with proper permissions on the client machine can read, write, and execute files
from the server. To setup the NFS system, one must have a network system installed
and working properly. Both the server and the client must also have the proper
software installed and running as the filesystem is brought online.
Most filesystem's are located on individual partitions but can also be files
located on the same partition. For example a loopback filesystem and cdrom (iso9660)
image can both be on a single partition; other types of mountable filesystems include
cdrom and floppy drives.
#------------------------------------------------------------------------------------
The NFS Server Setup:
portmap:
The 'portmap' application must be setup on the server machine.
Portmap should be started at this point and later be configured
to start during the bootstrap phase once the server if configured
for NFS services. Remote access to the portmap application is
governed by the host's files: hosts.allow and hosts.deny. You
should already understand the use of these files at this level.
The command 'rpcinfo -p' can be used to test the configuration
of these files.
rpc.mountd and rpc.nfsd:
These applications must be installed and running on the NFS
server. Check that these applications are installed and setup
to run during a bootstrap script.
To allow a filesystem called "/usr" on a server called "sapphire" to be
available to a client machine "garnet", the file "/etc/exports"
must be edited on the "sapphire" server as follows...
/etc/exports:
/usr garnet(rw)
Without the "rw" declaration, the garnet machine would have been granted
the default access which is read-only or "ro". You can avoid listing all
machines in the exports file by running NIS and using net groups and
specifying domain wildcards and IP-subnets as hosts that are allowed to
mount filesystems. Also, check the exports man page for more information.
Once changes are made to the /etc/exports file, you must restart the
mountd and dfsd daemons on your system. Some distributions contain an
application "exportfs" for restarting the services. If your distribution
does not contain such an application, make a script with the following
lines to do the same job...
/usr/sbin/exportfs:
#!/bin/sh
killall -HUP /usr/sbin/rpc.mountd
killall -HUP /usr/sbin/rpc.nfsd
#------------------------------------------------------------------------------------
The NFS Client Setup:
The client machine may require re-compiling the kernel with NFS filesystem
support or require a loadable module. If you are using a distribution such
as Redhat, you should not have to make any modifications to the system for
NFS filesystem support.
As the root user on the client machine, try to mount the server's filesystem
using the mount command...
% mount -o rsize=1024,wsize=1024 sapphire:/usr /mnt/tmp
The 'rsize' and 'wsize' option arguments are "read-size" and "write-size"
respectively. If not specified, the default is 4096, and 8192 respectively.
These defaults are not necessarily optimized for network transmissions and
most likely should be optimized for your network. The 1024 block size is a
good size to start with.
Mounting errors and their meanings:
mount: sapphire:/usr failed, reason given by server: Permission denied
If you receive an error for permission denied, check your setup in
the "/etc/exports" file. Make sure you ran the 'exportfs' command
when you made the changes or when you correct your mistakes.
mount clntudp_create: RPC: Program not registered
Make sure that 'mountd' and 'nfsd' is running on the server. Also,
check the 'hosts.allow' and 'hosts.deny' file configurations.
To unmount the filesystem, simply use the 'umount' command...
% umount /mnt/tmp
If you want your filesystem mounted during the clients bootstrap phase, you must
add an entry to the "/etc/fstab" file as you would with any other filesystem.
Make sure that your client is bringing up the network during bootstrap or this
obviously will not work.
sapphire:/usr /mnt/tmp nfs rsize=1024,wsize=1024 0 0
There are a extra options that can be added the the "/etc/fstab" entries for NFS
filesystems. These options govern the way the client handles a server crash or
network failure. The two different failure modes are as follows...
soft
The NFS client will report an error to the process accessing
a file on the NFS filesystem. Most programs cannot deal with
this situation properly and will lead to corrupted files and
lost data. This option should be avoided.
hard
The program accessing the NFS filesystem will hang when the
server crashes. The hung process cannot be interrupted or
killed unles you also specify the 'intr' option. When the
NFS server or network is back online, the hung program will
continue undisturbed. This 'hard,intr' option is preferred.
sapphire:/usr /mnt/tmp nfs rsize=1024,wsize=1024,hard,intr 0 0
#------------------------------------------------------------------------------------
Optimizing The NFS Network
To test the optimum read and write block size, mount the NFS filesystem and
perform a sequential write performance test, you must enable write access on
the server to perform these diagnostics...
% time dd if=/dev/zero of=/mnt/tmp/testfile bs=16k count=4096
This command creates a 64Mb file of zeroed bytes (that is large enough to
bypass any perceived performance caching may cause). If you have an large
amount of RAM, you may want to increase the filesize during the sequential
test. By performing about 5-10 tests you can get a good average of the NFS
filesystem performance. You will want to pay close attention to the 'elapsed'
or 'wall clock' timing.
Next, you will want to test the read performance of the NFS filesystem by
reading the file back to the client. Do this 5-10 times and average the
results...
% time dd if=/mnt/tmp/testfile of=/dev/null bs=16k
Now you can umount the NFS filesystem and remount it with a larger rsize and
wsize. You will most likely want to increase the block sizes in multiples of
1024 (eg. 1024, 2048, 3072, etc). The largest possible rsize and wsize block
size in NFS version 2 is 16384. An rsize and wsize that is too large is not
always immediately apparent. Incomplete file listings with 'ls' and no error
messages or reading files fails mysteriously is a symptom of a block size that
is too large.
Linux 1.3+ kernels perform read-ahead for rsizes that are larger or equal to
the machines page size. On the Intel platforms the page size is 4096. Read
ahead will significantly increase the NFS read performance. Therefore, on
Intel platforms, you will want a 4096 byte rsize if possible.
Once you have found the optimum rsize and wsize, update the "/etc/fstab" file
to reflect the optimum settings you have found.
#------------------------------------------------------------------------------------
NFS Security
If, on your server, you do not want to trust the root acount of a client, you can
specify an option in the "/etc/exports" file that will distrust the root user of
the client machine...
/usr diamond(rw,root_squash)
Now, if a root user of a client machine (UID 0) tries to access a file on the
NFS exported filesystem (read, write, or delete), the server substitutes the UID
of the root user on the client as the server's 'nobody' UID. In fact, on a Linux
machine running as an NFS server, the default is 'root_squash'. In order to allow
the root user to read, write, and delete on the server filesystem, one must put
the 'no_root_squash' in the "/etc/exports" file. Never export a filesytem to
'localhost' or '127.0.0.1".
To make sure the portmapper application on your distribution is a secure portmapper,
you the command...
% strings /usr/sbin/portmap | grep hosts
You should see the "/etc/hosts.allow" and "/etc/hosts.deny" files in the output.
This means that your portmapper application reads these files and therefore is a
more secure version.
The 'hosts.deny' file should contain the following to deny access to everyone...
portmap: ALL
The portmapper administrates nfsd, mountd, ypbind/ypserv, pcnfsd, and 'r' services
such as ruptime and rusers. You will want to allow access to some of these services
for machines on your local network. To allow access to clients on your local subnet,
place the following lines in the 'hosts.allow' file...
portmap: 192.168.1.0/255.255.255.0
For the portmap, you should only put ip addresses in the 'hosts.allow' file. Putting
hostnames will cause hostname lookups which will cause portmap activity which can
trigger other events which may cause a hole in the security of portmap.
You should also implement firewall security on the nfs and portmap ports. Nfsd
operates on port 2049 for both udp and tcp protocols. The portmapper operates on
port 111 for both udp and tcp. The mound operates on ports 745 and 747 for tcp and
udp respectively. You can check the ports with the 'rpcinfo -p' command.
For a optimum personal security, you should never access your PGP private key over
an NFS fileystem. A hacker which gains access to the system can setup trojans and
sniffers that will cache this access and compromise your PGP private key.
#------------------------------------------------------------------------------------
NFS Over Slow Connections
A slow line such as a modem or ISDN connection has a high amount a latency. There
are special configuration considerations when setting of NFS over these high
latency connections. The NFS is a slow protocol primarily intended for high speed
networks. FTP, HTTP, and RCP are all faster protocols than the NFS protocol which
was designed for convenience and diskless setups which cannot be supplemented by
the other protocols.
When setting up the an NFS filesystem of high-latency lines, you will want to use
the 'timeo' and 'retrans' mount options. The 'timeo' is a value in 1/10 of a second
before the first re-transmission after an RPC timeout. The default is 7 or 7/10 of
a second. After the first timeout, the timeout is doubled, then if another timeout
occurs, it is doubled again.
The 'restrans' option specifies the number of minor timeouts and retransmissions
that must occur before a major timout occurs. The default is 3 timeouts. When a
major timeout occurs, the file operation is either aborted or a "server not
responding" messege is printed to the console.
Therefore, with the default 'timeo' option of 0.7 (700ms), the NFS client will
repeat the request and double the timout to 1.4 seconds. If it does not receive a
reply within that time frame, the request is repeated again and the timout is
doubled once again to 2.8 seconds.
You can measure your line speed with a ping set to the same packet size as your
rsize and wsize options specified in the mount command or "/etc/fstab" file.
% ping -s 8192 sapphire
Pay attention to the time it takes to go to the "sapphire" server and return to
the client machine. Increase the 'timeo' according to the results. You must also
take into consideration other network traffic over the connection such as FTP
or HTTP. You may be running an HTTP and FTP server over these lines which will
increase the load from clients as well as the load given by your own usage.
#------------------------------------------------------------------------------------
Troubleshooting
Client:
RPC: Program not registered
is portmapper running?
is mountd running?
is nfsd running?
is portmapper forbidden to answer by "/etc/hosts.deny"?
Make sure the name resolution for the client is resolved to the
same name as specified in "/etc/exports".
Can the server do a lookuphostbyname or lookuphostbyaddr (lib functions)
on the client? Make sure the client can do...
% host
% host
Make sure the filesystem was not mounted after NFS services were started
on the server. If so, it is exporting underlying mount point, not the
mounted filesystem. Shut down nfsd and then restart it. The client must
also remount the filesystem.
Make sure the date is not off by a wide margin between both the server
and the client machines. You can also use NTP to synchronize the clocks
between the two machines. You can download this application from:
ftp://ftp.hackit.nl/pub/relay/pub/linux
The server cannot accept a mount from a user that belongs to more than
eight (8) groups. You must either use a different user or decrease the
groups the client user belongs to. The first is the most desirable.
If your client hangs trying to unmount an NFS filesytem, disallow the
umount process. It is not imperative to umount an NFS filesystem anyway.
The command is '% umount -avt nonfs'.