A Solaris system can share any of its file systems with other systems, making them available for remote mounting. NFS considers the system that shares the file system to be a server, and the system that remotely mounts the file system to be a client. When an NFS client mounts a remote file system, it is connected to a mount point on the local file system, which means it appears to local users as just another file system. For example, a system called carolina may make its mail directory /var/mail available for remote mounting by NFS clients. This would allow users on machines like georgia, virginia, and fairfax to read their mail—stored actually on carolina—locally from their own machines, without having to explicitly log in to carolina. This means that a single mail server, which acts as an NFS server, can serve all NFS clients on a local area network with mail. Figure 23-1 shows this configuration.
However, one important aspect of NFS is the ability to export file systems and mount them on a remote mount point that is different from the original shared directory. For example, the NFS server carolina may also export its Sun Answerbook files (from the directory /opt/answerbook) to the clients virginia, georgia, and fairfax. However, virginia mounts these files in the /usr/local/www/htdocs directory, as it publishes them via the world wide web, while georgia mounts them in /opt/doc/answerbook. The client fairfax mounts them in /opt/answerbook, just like they are exported from carolina. The point is that the remote mount point can be completely different from the actual directory exported by an NFS server. This configuration is shown in Figure 23-2.
NFS makes use of RPC technology, which makes it easy for systems to make requests for the remote execution of procedures on server systems. RPC is currently supported across a number of different operating systems, including Solaris, Linux, and Microsoft’s Windows. The purpose of RPC is to abstract the connection details and methods required to access procedures across networks—that is, the client and server programs do not need to implement separate networking code, because a simple API is provided for finding services through a service called the portmapper (or rpcbind). The portmapper should be running on at least the server for NFS to operate correctly.
The portmapper is registered with both UDP and TCP 111, because requests may be generated for, or received using, NFS 2 or NFS 3, respectively.