Purchase	Copyright © 2002 Paul Sheer. Click here for copying permissions.	Home

28. Network File System, NFS

This chapter covers NFS, the file-sharing capabilities of UNIX, and describes how to set up directories shareable to other UNIX machines.

As soon as one thinks of high-speed Ethernet, the logical possibility of sharing a file system across a network comes to mind. MS-DOS, OS/2, Apple Macintosh, and Windows have their own file-sharing schemes (IPX, SMB etc.), and NFS is the UNIX equivalent.

Consider your hard drive with its 10,000 or so files. Ethernet is fast enough that you should be able to entirely use the hard drive of another machine, transferring needed data as network packets as required; or you should be able to make a directory tree visible to several computers. Doing this efficiently is a complex task. NFS is a standard, a protocol, and (on LINUX) a software suite that accomplishes this task in an efficient manner. It is really easy to configure as well. Unlike some other sharing protocols, NFS merely shares files and does not facilitate printing or messaging.

28.1 Software

Depending on your distribution, the following programs may be located in any of the bin or sbin directories. These are all daemon processes. To get NFS working, they should be started in the order given here.

portmap

(also sometimes called rpc.portmap) This maps service names to ports. Client and server processes may request a TCP port number based on a service name, and portmap handles these requests. It is basically a network version of your /etc/services file.

rpc.mountd

(also sometimes called mountd) This handles the initial incoming request from a client to mount a file system and check that the request is allowable.

rpc.nfsd

(also sometimes called nfsd) This is the core--the file-server program itself.

rpc.lockd

(also sometimes called lockd) This handles shared locks between different machines on the same file over the network.

The acronym RPC stands for Remote Procedure Call. RPC was developed along with NFS by Sun Microsystems. It is an efficient way for a program to call a function on another machine and can be used by any service that needs to have efficient distributed processing. These days, its not really used for much except NFS, having been superseded by technologies like CORBA. [The ``Object-Oriented'' version of RPC] You can however, still write distributed applications with LINUX's RPC implementation.

28.2 Configuration Example

Sharing a directory with a remote machine requires that forward and reverse DNS lookups be working for the server machine as well as all client machines. DNS is covered in Chapter 27 and Chapter 40. If you are just testing NFS and you are sharing directories to your local machine (which we do now), you may find NFS to still work without a proper DNS setup. You should at least have proper entries in your /etc/hosts file for your local machine (see page ).

The first step is deciding on the directory you would like to share. A useful trick is to share your CD-ROM to your whole LAN. This is perfectly safe considering that CDs are read-only. Create an /etc/exports file with the following in it:

/mnt/cdrom   192.168.1.0/24(ro)  localhost(ro)

You can immediately see that the format of the /etc/exports file is simply a line for each shareable directory. Next to each directory name goes a list of hosts that are allowed to connect. In this case, those allowed access are all IP addresses having the upper 24 bits matching 192.168.1, as well as the localhost.

Next, mount your CD-ROM as usual with

mkdir -p /mnt/cdrom mount -t iso9660 -o ro /dev/cdrom /mnt/cdrom

Now start each of the NFS processes in sequence:

portmap rpc.mountd rpc.nfsd rpc.lockd

Whenever you make changes to your /etc/exports file you should also follow by running

exportfs -r

which causes a rereading of the /etc/exports file. Entering the exportfs command with no options should then show

/mnt/cdrom      192.168.1.0/24 /mnt/cdrom      localhost.localdomain

which lists directories and hosts allowed to access them.

It is useful to test mounts from your local machine before testing from a remote machine. Here we perform the NFS mounting operation proper:

mkdir /mnt/nfs mount -t nfs localhost:/mnt/cdrom /mnt/nfs

You can see that the mount command sees the remote machine's directory as a ``device'' of sorts, although the type is nfs instead of ext2, vfat, or iso9660. The remote host name is followed by a colon followed by the directory on that remote machine relative to the root directory. This syntax is unlike that for other kinds of services that name all files relative to some ``top level'' directory (eg., FTP and web servers). The acid test now is to run ls on the /mnt/nfs directory to verify that its contents are indeed the same as /mnt/cdrom. Supposing our server is called cdromserver, we can run the same command on all client machines:

mkdir /mnt/nfs mount -t nfs cdromserver:/mnt/cdrom /mnt/nfs

If anything went wrong, you might like to search your process list for all processes with an rpc, mount, nfs, or portmap in them. Completely stopping NFS means clearing all of these processes (if you really want to start from scratch). It is useful to also keep

tail -f /var/log/messages tail -f /var/log/syslog

running in a separate console to watch for any error (or success) messages (actually true of any configuration you are doing). Note that it is not always obvious that NFS is failing because of a forward or reverse DNS lookup, so double-check beforehand that these are working-- mount will not usually be more eloquent than the classic NFS error message: `` mount: <xyz> failed, reason given by server: Permission denied.'' A faulty DNS is also indicated by whole-minute pauses in operation.

Most distributions will not require you to manually start and stop the daemon processes above. Like most services, RedHat's NFS implementation can be invoked simply with:

/etc/init.d/nfs start /etc/init.d/nfslock start

(or /etc/rc.d/init.d/). On Debian, similarly,

/etc/init.d/nfs-common start /etc/init.d/nfs-kernel-server start

28.3 Access Permissions

Above, we used 192.168.1.0/24(ro) to specify that we want to give read- only access to a range of IP addresses. You can actually put host names with wildcards also; for example:

/mnt/cdrom   *.mynet.mydomain.co.za(ro)

Then also allow read- write access with, say:

/home   *.mynet.mydomain.co.za(rw)

One further option, no_root_squash, disables NFS's special treatment of root-owned files. This option is useful if you are finding certain files strangely inaccessible. no_root_squash is really only for systems (like diskless workstations) that need full root access to a file system. An example is:

/   *.very.trusted.net(rw,no_root_squash)

The man page for /etc/exports, exports(5), contains an exhaustive list of options.

28.4 Security

NFS requires that a number of services be running that have no use anywhere else. Many naive administrators create directory exports with impunity, thus exposing those machines to opportunistic hackers. An NFS server should be well hidden behind a firewall, and any Internet server exposed to the Internet should never run the portmap or RPC services. Preferably uninstall all of these services if you are not actually running an NFS server.

28.5 Kernel NFS

There are actually two versions of the NFS implementation for LINUX. Although this is a technical caveat, it is worth understanding that the NFS server was originally implemented by an ordinary daemon process before the LINUX kernel itself supported NFS. Debian supports both implementations in two packages, nfs-server and nfs-kernel-server, although the configuration should be identical. Depending on the versions of these implementations and the performance you require, one or the other may be better. You are advised to at least check the status of the kernel NFS implementation on the kernel web pages. Of course, NFS as a client must necessarily be supported by the kernel as a regular file system type in order to be able to mount anything.