Written by Bill Swingle <unfurl@FreeBSD.org>, 4 March 2000.
Among the many different file systems that FreeBSD supports is a very unique type, the Network File System or NFS. NFS allows you to share directories and files on one machine with one or more other machines via the network they are attached to. Using NFS, users and programs can access files on remote systems as if they were local files.
NFS has several benefits:
Local workstations dont need as much disk space because commonly used data can be stored on a single machine and still remain accessible to everyone on the network.
There is no need for users to have unique home directories on every machine on your network. Once they have an established directory that is available via NFS it can be accessed from anywhere.
Storage devices such as floppies and CD-ROM drives can be used by other machines on the network eliminating the need for extra hardware.
NFS is composed of two sides - a client side and a server side. Think of it as a want/have relationship. The client wants the data that the server side has. The server shares its data with the client. In order for this system to function properly a few processes have to be configured and running properly.
The server has to be running the following daemons:
nfsd - The NFS Daemon which services requests from NFS clients.
mountd - The NFS Mount Daemon which actually carries out requests that nfsd passes on to it.
The client side only needs to run a single daemon:
nfsiod - The NFS async I/O Daemon which services requests from its NFS server.
Luckily for us, on a FreeBSD system this setup is a snap. The processes that need to be running can all be run at boot time with a few modifications to your /etc/rc.conf file.
On the NFS server make sure you have:
nfs_server_enable="YES"
nfs_server_flags="-u -t -n 4"
mountd_flags="-r"
mountd is automatically run whenever the NFS server is enabled. The -u and -t flags to nfsd tell it to serve UDP and TCP clients. The -n 4 flag tells nfsd to start 4 copies of itself.
On the client, make sure you have:
nfs_client_enable="YES"
nfs_client_flags="-n 4"
Like nfsd, the -n 4 tells nfsiod to start 4 copies of itself.
The last configuration step requires that you create a file called /etc/exports. The exports file specifies which file systems on your server will be shared (a.k.a., ``exported'') and with what clients they will be shared. Each line in the file specifies a file system to be shared. There are a handful of options that can be used in this file but I will only touch on a few of them. You can find out about the rest in the exports(5) man page.
Here are a few example /etc/exports entries:
The following line exports /cdrom to three silly machines that have the same domain name as the server (hence the lack of a domain name for each) or have entries in your /etc/hosts file. The -ro flag makes the shared file system read-only. With this flag, the remote system will not be able to make any changes to the the shared file system.
/cdrom -ro moe larry curly
The following line exports /home to three hosts by IP address. This is a useful setup if you have a private network but do not have DNS running. The -alldirs flag allows all the directories below the specified file system to be exported as well.
/home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4
The following line exports /a to two machines that have different domain names than the server. The -maproot=0 flag allows the root user on the remote system to write to the shared file system as root. Without the -maproot=0 flag even if someone has root access on the remote system they won't be able to modify files on the shared file system.
/a -maproot=0 host.domain.com box.example.com
In order for a client to share an exported file system it must have permission to do so. Make sure your client is listed in your /etc/exports file.
Now that you have made all these changes you can just reboot and let FreeBSD start everything for you at boot time or you can run the following commands as root:
On the NFS server:
# nfsd -u -t -n 4
# mountd -r
On the NFS client:
# nfsiod -n 4
Now you should be ready to actually mount a remote file system. This can be done one of two ways. In these examples the server's name will be server and the client's name will be client. If you just want to temporarily mount a remote file system or just want to test out your config you can run a command like this as root on the client:
# mount server:/home /mnt
This will mount /home on the server on /mnt on the client. If everything is setup correctly you should be able to go into /mnt on the client and see all the files that are on the server.
If you want to permanently (each time you reboot) mount a remote file system you need to add it to your /etc/fstab file. Here is an example line:
server:/home /mnt nfs rw 0 0
Read the fstab(5) man page for more options.
There are many very cool uses for NFS. I use it quite a bit on the LAN I admin. Here are a few ways I have found it to be useful.
I have several machines on my network but only one of them has a CD-ROM drive. Why? Because I have that one CD-ROM drive shared with all the others via NFS. The same can be done with floppy drives.
With so many machines on the network it gets old having your personal files strewn all over the place. I have a central NFS server that houses all user home directories and shares them with the rest of the machines on the LAN, so no matter where I login I have the same home directory.
When you get to reinstalling FreeBSD on one of your machines, NFS is the way to go. Just pop your distribution CD into your file server and away you go.
I have a common /usr/ports/distfiles directory that all my machines share. That way when I go to install a port that I already installed on a different machine I do not have to download the source all over again.
Contributed by John Lind <john@starfire.MN.ORG>.
Certain Ethernet adapters for ISA PC systems have limitations which can lead to serious network problems, particularly with NFS. This difficulty is not specific to FreeBSD, but FreeBSD systems are affected by it.
The problem nearly always occurs when (FreeBSD) PC systems are networked with high-performance workstations, such as those made by Silicon Graphics, Inc., and Sun Microsystems, Inc. The NFS mount will work fine, and some operations may succeed, but suddenly the server will seem to become unresponsive to the client, even though requests to and from other systems continue to be processed. This happens to the client system, whether the client is the FreeBSD system or the workstation. On many systems, there is no way to shut down the client gracefully once this problem has manifested itself. The only solution is often to reset the client, because the NFS situation cannot be resolved.
Though the ``correct'' solution is to get a higher performance and capacity Ethernet adapter for the FreeBSD system, there is a simple workaround that will allow satisfactory operation. If the FreeBSD system is the server, include the option -w=1024 on the mount from the client. If the FreeBSD system is the client, then mount the NFS file system with the option -r=1024. These options may be specified using the fourth field of the fstab entry on the client for automatic mounts, or by using the -o parameter of the mount command for manual mounts.
It should be noted that there is a different problem, sometimes mistaken for this one, when the NFS servers and clients are on different networks. If that is the case, make certain that your routers are routing the necessary UDP information, or you will not get anywhere, no matter what else you are doing.
In the following examples, fastws is the host (interface) name of a high-performance workstation, and freebox is the host (interface) name of a FreeBSD system with a lower-performance Ethernet adapter. Also, /sharedfs will be the exported NFS filesystem (see man exports), and /project will be the mount point on the client for the exported file system. In all cases, note that additional options, such as hard or soft and bg may be desirable in your application.
Examples for the FreeBSD system (freebox) as the client: in /etc/fstab on freebox:
fastws:/sharedfs /project nfs rw,-r=1024 0 0
As a manual mount command on freebox:
# mount -t nfs -o -r=1024 fastws:/sharedfs /project
Examples for the FreeBSD system as the server: in /etc/fstab on fastws:
freebox:/sharedfs /project nfs rw,-w=1024 0 0
As a manual mount command on fastws:
# mount -t nfs -o -w=1024 freebox:/sharedfs /project
Nearly any 16-bit Ethernet adapter will allow operation without the above restrictions on the read or write size.
For anyone who cares, here is what happens when the failure occurs, which also explains why it is unrecoverable. NFS typically works with a ``block'' size of 8k (though it may do fragments of smaller sizes). Since the maximum Ethernet packet is around 1500 bytes, the NFS ``block'' gets split into multiple Ethernet packets, even though it is still a single unit to the upper-level code, and must be received, assembled, and acknowledged as a unit. The high-performance workstations can pump out the packets which comprise the NFS unit one right after the other, just as close together as the standard allows. On the smaller, lower capacity cards, the later packets overrun the earlier packets of the same unit before they can be transferred to the host and the unit as a whole cannot be reconstructed or acknowledged. As a result, the workstation will time out and try again, but it will try again with the entire 8K unit, and the process will be repeated, ad infinitum.
By keeping the unit size below the Ethernet packet size limitation, we ensure that any complete Ethernet packet received can be acknowledged individually, avoiding the deadlock situation.
Overruns may still occur when a high-performance workstations is slamming data out to a PC system, but with the better cards, such overruns are not guaranteed on NFS ``units''. When an overrun occurs, the units affected will be retransmitted, and there will be a fair chance that they will be received, assembled, and acknowledged.
For questions about FreeBSD, e-mail
<questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.