Introduction to NFS

Windows uses NetBIOS/SMB/CIFS for its file sharing, and Macintoshes use AppleTalk or AppleShare/IP. These are all peer-to-peer protocols, with each system broadcasting its presence onto the LAN, and all machines being able to mount each other's shared folders dynamically. NFS is a bit different in that it's a client/server protocol, with designated servers sharing items that can be mounted remotely by specified NFS clients. This model is designed for centralized file servers, as is common in enterprise or university networks, rather than for peer-to-peer file transfers. However, with the proper configuration, NFS can do almost everything that the other protocols can do, and more, with the exception of server discovery.

Under both Windows and the Mac OS, the built-in filesharing protocol on a computer broadcasts information about its own shared folders (or shares) and asks for responses about other available shares on the network. These "discovery" queries and responses are sent out by each machine on the network and trigger frequent responses from all other machinesresulting in a very "chatty" network environment. NFS doesn't have a corresponding discovery mechanism. As you will see, each NFS client has to know where to find each server and mount it manually. However, this does mean that the network is much quieter due to a lack of discovery traffic.

Tip

The Service Location Protocol (SLP) is a separate technology that allows for the automatic discovery and browsing of network resources such as NFS shares. You can install the OpenSLP package (in the net category of the ports or packages) to give your FreeBSD machine the capability to discover NFS shares on the network; modern versions of Windows and Mac OS X have SLP functionality built into their filesystem browsers. Without SLP, though, you have to know the name and location (and authentication requirements) of any NFS share you try to mount.

This less-convenient structure of NFS does have its benefits. The centralized model provides better security; a server can control exactly which clients are able to connect to itfor example, by hostname or IP address, or by centralized login, as with NIS or Kerberos. Another feature of NFS is that because it does not depend on LAN broadcasts for server discovery, it can be used across the Internet just as easily as across the LAN. A client in Boston can mount a share from a server in San Francisco, if necessary. By contrast, NetBIOS/SMB/CIFS and AppleTalk only can operate within "domains" or "zones" on the local network, or over a VPN tunnel where all hosts are topologically on the same LAN (although AppleShare/IP can cross the Internet freely).

As far as FreeBSD is concerned, NFS is a filesystem just like any other. You can mount an NFS share over the network just as if you were mounting a floppy disk or a new hard drive partition, as you saw in Chapter 12, "The FreeBSD Filesystem." Shares can even be mounted automatically if their resources are requested. We will go over the procedure of mounting an NFS share manually and automatically later in this chapter.

The client/server structure of NFS is designed so that you can centralize the resources in your network. For example, an enterprise might give all its employees home directories on a central UNIX machine, and every other system in the network that supports NFS will be able to mount those home directories and access them remotely, rather than requiring each machine to have its own copy of every home directory. Figure 33.1 shows this kind of network topology in action. The same can be done for build directories (in a software development environment) or shared applications that are centrally installed (as in a university workstation cluster). NFS mounts can be used in conjunction with NIS (centralized login management) to provide the entire network with user authentication; then, file ownership and permissions on every file in a mounted share will work just as on the NFS server machine itself. You can even install FreeBSD over NFS if you mount the installation DVD on the NFS server and point Sysinstall toward it.

Figure 33.1. An enterprise network with central NFS-mounted home directories.

An interesting aspect of NFS is that it's primarily based on UDP rather than TCP. As you learned in Chapter 22, "Principles of TCP/IP Networking," UDP has none of the reliability or connection-centric structure of TCP and is inherently unreliable. Although it seems odd that a data-conscious network protocol would use UDP as its transport mechanism, spewing datagrams from server to client without any guarantee of their integrity, NFS is actually one of the best examples of UDP used properly. Full TCP connections aren't really needed, especially on a LAN. NFS clients come and go as machines on a network come up and shut down, and TCP connections would just get in the way of data streams sending files and directory information back and forth between the endpoints on request. An NFS mount can stay dormant for days and then suddenly be called into use again. UDP allows the shared resources to be immediately available without connection startup overhead or lag time, and if a host drops off the network, it's no big deal to the server.

Data integrity is maintained by the NFS software itself, higher up the OSI stack in the application layer, keeping checksum and sequencing information in the packets' payload and doing all the work that TCP would otherwise have done. However, NFS clients that operate over TCP do exist, and the NFS server supports them, too. NFS over TCP is primarily intended for mounts that take place over a WAN, in which dropped packets are much more likely, and the benefits of full TCP connections mitigate the benefits that UDP offers on LAN connections. TCP-based NFS can also be useful for firewall administrators who need to know a predictable TCP port on which to allow NFS traffic (UDP-based traffic tends to use large and unpredictable port ranges that confound firewall configurations).

Note

One downside to using UDP, though, is that if a client tries to contact an NFS server that isn't there, it can take forever to time out. The lack of a full TCP connection means that more primitive methods are necessary to determine whether a server is not responding. We will talk about some of the ways to avoid running into the lengthy NFS timeout later in this chapter.

Caution

NFS doesn't have any built-in encryption, so it should be used over the Internet only if you're working with files that can be safely exposed to the public. Mission-critical or sensitive data should never be sent over wide-area NFS, except through an encrypted VPN tunnel.

A FreeBSD machine can be configured to be an NFS server, an NFS client, or both. Depending on how you configure it, the system will run a few different processes that manage the end of the NFS connections it will handle. We'll talk first about setting up a FreeBSD machine as an NFS server and then about configuring it as a client.