The Network File System (NFS) is the grand matron of contemporary network-based file serving. NFS pre-dates Novell NetWare, Microsoft/3Com LAN Manager, IBM LAN Server, and all the other PC-oriented file-serving methods. Until recently, however, NFS has been a UNIX-only solution for workgroup-oriented file serving. The introduction of NFS products to the PC market and, more importantly, the Windows NT market has breathed new life into NFS.
NFS was developed by Sun Microsystems as the file-serving component in its Open Network Computing (ONC) architecture. ONC provides a broad range of Transmission Control Protocol/Internet Protocol (TCP/IP)-based networking services, but it is best known for its Remote Procedure Call (RPC) and NFS components. The "open" nature of Sun's ONC architecture allowed other UNIX vendors to port ONC components to their own unique environments, and NFS soon became a de facto standard for file sharing on UNIX networks.
NFS in Action
In a seashell, NFS allows a system to access designated directories (including all files and subdirectory entries) on other systems over a TCP/IP network. Like Windows for Workgroups (WFW), Windows 95, and Windows NT Workstation, NFS is a peer-oriented solution that allows multiple systems to mount common directories and doesn't demand a dedicated server (although you can implement one).
As you probably suspect, NFS follows the client/server model. NFS clients and servers communicate using Sun's RPC architecture, which operates over the TCP/IP User Datagram Protocol (UDP) transport. With this architecture, NFS clients contact a "port mapper" program on the server, and the port mapper translates the RPC service requests into specific TCP/IP sockets serviced by the local NFS server. Also remember that under the peer-orientation of NFS, a given UNIX system is typically both an NFS client and an NFS server.
To access a directory over the network, the NFS server program must be informed which directories are available for network access, which client systems can access those directories, and what access rights are associated with the various client/directory combinations. The exact method of configuring this information varies from one UNIX implementation to another. For example, Sun systems use the share command to make directories available for network access, while most other UNIX implementations usually configure the directory information in a file called "exports."
On the client side, an NFS client requests access to an NFS server directory during the boot process or through an interactive mount command. When the NFS server receives the request (via the port mapper program), it compares the requested directory to its list of available directories and authorized client systems. Based on the results of that comparison, the NFS server will either make that directory available to the client (under the control of the associated access rights) or reject the request.
Once the client request is satisfied, the client system can access the NFS directory as if it were a local directory entry. For example, an NFS client system named kirk could initiate the following command: mount spock:/users /susers
If the NFS server system named spock were configured to allow kirk to mount its /users directory, the request would be satisfied. A user working on system kirk could then change to the /susers local directory and access the files and subdirectories that are stored in the users directory on system spock.
In reality, admittance to specific files and subdirectories in a mounted directory is further controlled by the access rights assigned to the individual users on the client system. Even though system kirk can mount the /users directory on system spock, that doesn't necessarily mean that all the users assigned to kirk can access the information in the mounted directory.
This brief look at NFS brings two important items to light. First, you should be able to see a strong similarity between NFS and the file-sharing approach supported by WFW, NT, and Windows 95. This makes it easy for the same individual to manage or work with both Microsoft and NFS file sharing. Second, NFS servers assume that the requesting NFS client enforces user authentication and access rights. In other words, the NFS server trusts that the client won't allow dangerous users--by innocence or intent--to access important or sensitive files.
Enter the PC
For years, NFS remained a UNIX-only offering. Then, in the late 1980s, Sun Microsystems brought PCs into the NFS fold with the introduction of PC-NFS. The intent of this product was to allow PCs to participate in NFS networks as NFS clients. Using PC-NFS, PCs can access UNIX directories as if they were network drives. For example, the /users directory on NFS server system spock could be mounted on the PC as network drive S.
Integrating PCs into NFS posed some problems for PC-NFS developers. First, the PC environment at that time didn't support long filenames: The eight-character filename and three-character extension was the law of the land. Second, PCs didn't provide any means of user authentication or access control: Anybody who sat down at a PC keyboard was, in essence, a "superuser."
Fortunately, the developers of PC-NFS were able to solve both problems. An algorithm was developed to translate between UNIX names and legal DOS filenames. Thus, DOS-based NFS clients could see and access UNIX files with long filenames, even though the filename might seem peculiar (e.g., testin~1.tes instead of testingfile.test). This translation occurs on the PC side of the NFS connection, allowing PC-NFS to be compatible with existing NFS server software.
Addressing the potential security problem of PC-based users did, however, require introducing new software into the NFS server system. Specifically, Sun created a new server program called the PC-NFS daemon. The PCNFSD program performs two important functions for PC-NFS:
For years, Sun's PC-NFS was the only significant NFS integration product for the PC market. As the popularity of UNIX increased, however, more and more TCP/IP software vendors introduced NFS products for the PC market. For example, FTP Software, NetManage, and Walker Richer & Quinn (WRQ), now offer NFS products for the PC market. Although these products can't legally be called PC-NFS, they all support the basic architecture established by the Sun product.
NFS and NT
Given the importance of NFS in the world of UNIX networking, the introduction of NFS products into the NT market is significant for two reasons. First, it allows Windows NT Workstations and Servers to be fully integrated into existing UNIX networks. NT users and applications can mount UNIX-based directories and access the associated information. Similarly, UNIX systems can mount NT directories using standard NFS services and treat them just like any other UNIX directory.
Second, and more importantly, NFS products for NT are a strategic tool used to introduce NT Servers into large or complex multivendor environments. For example, in a mixed PC and UNIX environment, an NT Server with NFS services can be placed on the network and provide file, print, and application services for both PC and UNIX systems. PCs can access the NT Server using traditional PC LAN services (e.g., LAN Manager, WFW, Windows 95), and UNIX systems can access the same NT Server using NFS. In fact, they can even access the same directories.
In multivendor environments, this is just the tip of the iceberg. When you add other NT integration services to the mix, NT Server can become a core component in large, multivendor enterprise networks. PCs, UNIX systems, IBM systems, and even NetWare clients and servers can all be integrated through the NT Server. In this respect, NFS services are just one component of a larger solution. But, if you are sitting at a UNIX system, NFS is a very important component.