Table of Contents DOS
TCP/IP Tutorial and Technical Overview

4.12 Network File System (NFS)




Figure: Network File System (NFS)

The SUN Microsystems Network File System (NFS) protocol enables machines to share file systems across a network. The NFS protocol is designed to be machine-, operating system-, and transport protocol-independent. This is achieved through implementation on top of Remote Procedure Call (see Remote Procedure Call (RPC)). RPC establishes machine independence by using the External Data Representation convention.

SUN-NFS is a proposed standard protocol. Its status is elective. The current Sun-NFS specification can be found in RFC 1094 - NFS: Network File System Protocol specification. This RFC documents NFS Version 2. Although this RFC mentions an NFS Version 3, nobody has submitted a new RFC nor an Internet-Draft discussing a possible Version 3 specification.

4.12.1 Concept

NFS allows authorized users to access files located on remote systems as if they were local. Two protocols serve this purpose:

  1. The Mount protocol to specify the remote host and file system to be accessed and where to locate them in the local file hierarchy.
  2. The NFS protocol to do the actual file I/O to the remote file system.
Both Mount and NFS protocol are RPC applications (caller/server concept) and are transported by UDP.

4.12.1.1 Mount Protocol

The Mount protocol is an RPC-application shipped with NFS. It is program number 100005. The Mount protocol is transported by UDP. Mount is an RPC-server program and provides a total of six procedures:
NULL
Does nothing, useful for server response testing.
MOUNT
Mount function, returns a file handle pointing to the directory.
DUMP
Returns the list of all mounted file systems.
UMOUNT
Removes a mount list entry.
UNMTALL
Removes all mount list entries for this client.
EXPORT
Returns information about the available file systems.
The MOUNT-call returns a file handle to the directory. The file handle is a 32-byte field, which will be used subsequently by the client to access files. File handles are a fundamental part of NFS because each directory and file will be referenced through a handle. Some implementations will encrypt the handles for security reasons (for example, NFS on VM can optionally use the VM encryption programs to provide this).

The user interface to this RPC application is provided through the MOUNT command. The user issues a MOUNT command to locate the remote file system in his own file hierarchy.

For example, consider a VM NFS server. The concept of subdirectories (hierarchical file system) does not exist here; there are only minidisks (to be considered as one directory each). Now consider an AIX client (AIX does have a subdirectory file system). The client can access the user 191 VM minidisk as its local subdirectory /u/vm/first by issuing the MOUNT command: 

MOUNT -o options
       host:user.191,ro,pass=password,record=type,names=action
       /u/vm/first
Where:
options
System options such as message size.
host
The TCP/IP name of the remote host.
user
VM user ID.
191
Minidisk address.
pass=
Link password that will allow the NFS machine to access the minidisk.
record=
Specifies what translation processing is to be done on the CMS records:
binary
No processing performed.
text
Code conversion between EBCDIC (server) and ASCII (client).
nl
EBCDIC-to-ASCII translation, and new line characters are interpreted as CMS record boundaries.
names=
Specifies the handling of a file name:
fold
file names supplied by the client are translated to uppercase.
mixed
file names are used as supplied by the client.
If no name translation option is specified, case folding is performed and, in addition, client names that are not valid in CMS will be converted into valid CMS names.
The result is that the VM minidisk is now seen by the client machine as a local subdirectory:


Figure: NFS Mount Command - The client mounts the VM minidisk user.191 as its local directory /u/vm/first.

Obviously, the previous command: 

MOUNT -o options host:user.191,ro,pass=password,record=type,names=action
/u/vm/first
has three parts:
  1. -o options is the client part. It has to be understood by the NFS client only. This means, it depends on the client host and is documented in the client's documentation.
  2. host:user.191,ro,....,names=action is the server part. The syntax depends on the server's file system (obviously, user.191 does not mean anything to an MVS NFS server). Refer to the documentation of the NFS server to know what parameters it will accept.
  3. /u/vm/first is a client part and is called the mount point, that is, where the remote file system will be hooked on the local file system.

The UMOUNT command removes the remote file system from the local file hierarchy. Following the example above: 

UMOUNT /u/vm/first
will remove the /u/vm/first directory.

4.12.1.2 NFS Protocol

NFS is the RPC application program providing file I/O functions to a remote host, once it has been requested through a MOUNT command. It has program number 100003 and sometimes uses IP port 2049. As this is not an officially assigned port and several versions of NFS (and mount) already exist, port numbers may change. It is advised to go to Portmap (port number 111) (see Portmap or Portmapper) to obtain the port numbers for both Mount and NFS. The NFS protocol is transported by UDP.

The NFS program supports 18 procedures, providing for all basic I/O operations such as:

LOOKUP
Searches for a file in the current directory and if found, returns a file handle pointing to it plus information on the file's attributes.
READ and WRITE
Basic read/write primitives to access the file.
RENAME
Renames a file.
REMOVE
Deletes a file.
MKDIR and RMDIR
Creation/deletion of subdirectories.
GET and SET-ATTR
Gets or sets file attributes.
Other functions are also provided.

These correspond to most of the file I/O primitives used in the local operating system to access local files. In fact, once the remote directory is mounted, the local operating system just has to "re-route" the file I/O primitives to the remote host. This makes all file I/Os look alike, regardless of whether the file is located locally or remotely. The user can operate his normal commands and programs on both kinds of files; in other words, this NFS protocol is completely transparent to the user. See Figure - NFS File I/O.


Figure: NFS File I/O - Intercepted at the operating system level, thereby making it transparent to the user.

4.12.1.3 NFS File System

NFS assumes a hierarchical file system (directories). Files are unstructured streams of uninterpreted bytes; that is, files are seen as a contiguous byte stream, without any record-level structure.

This is the kind of file system used by AIX and PC/DOS, so these environments will easily integrate an NFS-client extension in their own local file system. File systems used in VM and MVS lend themselves less readily to this kind of extension.

With NFS, all file operations are synchronous. This means that the file-operation call only returns when the server has completed all work for this operation. In case of a write request, the server will physically write the data to disk and if necessary, update any directory structure, before returning a response to the client. This ensures file integrity.

NFS also specifies that servers should be stateless. That is, a server does not need to maintain any extra information about any of its clients in order to function correctly. In case of a server failure, clients only have to retry a request until the server responds, without having to reiterate a mount operation.

4.12.2 Implementations

4.12.2.1 VM

TCP/IP for VM includes the NFS server function only. This means that other hosts running NFS will be able to access VM minidisks, but that the VM user is not able to access the remote hosts' file systems.

The VM NFS server uses UDP port number 2049. It also requires that the PORTMAP virtual machine be started.

The VM NFS server saves information about the file handles it distributes to clients in the file VMNFS HISTORY. This is done because the 32-byte file handle cannot hold all information needed to uniquely identify a CMS file. So, instead, each file handle is associated with a record of the history file. The VMNFS HISTORY will also record the CP LINK password the client sends when he wants to access a minidisk. Appropriate actions should be taken to ensure security of this file (on NFS 191 disk).

To prevent a client from manipulating the contents of an obtained file handle, provision is made for encryption of these file handles. The client must return this encrypted file handle for each file operation. The NFSFHCIP ASSEMBLE file is shipped with the product. It invokes a subroutine to encode or decode a file handle. As shipped, it will call the Information Protection System Cryptographic Programs for VM/CMS, program number 5796-PPK. This file should be modified to contain the cryptographic key needed for the encryption. By changing the assembly source, one may also call upon other cryptographic programs, or not use any encoding at all. The VMNFS MODULE will need to be rebuilt only if some form of encryption is used. See IBM TCP/IP Version 2 Release 3 for VM: Planning and Customization for more information on encryption and for other installation parameters.

Another security feature for the VM NFS implementation is the possibility to send the CP LINK password (sent by client to the server) separately from the MOUNT command, because all the information transmitted with the MOUNT command (passwords for example) are stored on the client. This is provided through the MOUNT -v or MOUNTPW commands.

If RACF is installed on your server, it can be used to secure the access to the minidisks. Please refer to IBM TCP/IP Version 2 Release 3 for VM: Planning and Customization for more details.

The VM NFS server uses, when possible, the multiple-block *BLOCKIO, a fast VM Control Program system service, to improve the write operations.

The SMSG command allows an authorized user to transmit commands to NFS while NFS is executing. For example, displaying a summary of its activity, detaching a mounted minidisk, writing internal trace table to disk, or refreshing a mounted minidisk.

The following shows a sample output from a query command. 

SMSG VMNFS M QUERY
MSG FROM VMNFS   : M 200 ro  TCPMAINT.192
MSG FROM VMNFS   : M VM NFS server start time 02Apr91 13:12:21.
MSG FROM VMNFS   : M   2 RPC (0 duplicate XID),  4 SMSG, 4 *BLOCKIO
MSG FROM VMNFS   : M   0 null, 0 getattr, 0 setattr, 0 lookup, 0 read, 0 write
MSG FROM VMNFS   : M   0 create, 0 remove, 0 rename, 0 readdir, 1 statfs
MSG FROM VMNFS   : M   1 mount, 0 mountpw, 0 mountnull, 0 unmount, 0 unsupported
MSG FROM VMNFS   : M End of reply.



The SHOWEXP command is not supported. That is, you cannot display from a client the export list (the minidisks that can be mounted) of a VM NFS server.

An alternative NFS implementation for the VM/ESA environment is LAN File Services/ESA.

4.12.2.2 MVS

NFS in the MVS environment is delivered as part of Data Facility Systems Managed Storage/MVS (DFSMS/MVS). NFS in the MVS environment supports the server function only.

It provides access to data sets for users of workstations which support the NFS client function. NFS uses the MVS access methods to read, write, create or delete MVS data sets.

The NFS server reads or writes binary and text data. In a file that contains text, record boundaries are translated into line terminators. A file that contains binary data is stored in the MVS system and retrieved without text translation.

In order to get access to the NFS server, an NFS client will be required to submit a user ID and password. This security function is provided by PCNFSD. PCNFSD replaces the mvslogin and mvslogout commands which performed a similar function in earlier MVS NFS implementations.

Unlike VM, the SHOWEXP command is supported.

An alternative NFS implementation for the MVS/ESA environment is LAN File Services/ESA.

With LFS/ESA on MVS, an NFS client is able to access OpenEdition MVS Hierarchical File System (HFS) files on MVS.

4.12.2.3 OS/400

NFS for OS/400 is available by installing the TCP/IP File Server Support/400. This product allows other systems to access AS/400 system files (both Native Database and Shared Folder).

TCP/IP File Server Support/400 is a server only implementation of NFS.

TCP/IP File Server Support/400 supports NFS Protocol Version 2. TCP/IP File Server Support is designed to be compatible with clients running ONC/NFS Version 4.x.

NFS support (NFS/400) will be integrated into OS/400 in 1995. The new NFS support will provide both client and server capability and will be compatible with SUN Microsystems NFS.

4.12.2.4 AIX/6000

NFS on RISC System/6000 supports:

Information about NFS on all AIX implementations has been collected in the publication: AIX Distributed Environments, GG24-3489.

4.12.2.5 AIX/ESA

NFS for IBM AIX/ESA Version 2 Release 1 supports:

It is compliant with SUN NFS Version 2.

4.12.2.6 OS/2

TCP/IP for OS/2 includes the NFS client and server functions.

The client runs in the NFSCTL program. The following commands are shipped with the product:

The OS/2 NFS server is started by the NFSD command. It requires Portmap to be started via the PORTMAP command. It also requires the \ETC\EXPORTS file which is read only during NFSD startup. Please refer to IBM TCP/IP Version 2.0 for OS/2: Installation and Administration for more considerations about the \ETC\EXPORTS file.

PCNFSD support is provided in the OS/2 NFS Server.

4.12.2.7 DOS

TCP/IP for DOS includes the NFS client function only. Both native DOS and Microsoft Windows implementations are provided in a separately orderable kit.

The following commands are available:

Please refer to IBM TCP/IP Version 2.1.1 for DOS: User's Guide for more details about the NFS commands.

Table of Contents Kerberos Authentication and Authorization System