The Network File System (NFS) protocol is a TCP/IP application that supports networked filesystems. It provides transparent access to shared filesystems across networks.
NFS lets a client computer operate on files that reside on a server across a variety of NFS-compliant operating systems. File access calls from a client are converted to NFS protocol (see RFC 1094 and RFC 1813) requests, and are sent to the server over the network. The server receives the request, performs the actual filesystem operation, and sends a response back to the client.
In essence, NFS lets you graft remote filesystems—or portions of them—onto your local namespace. Directories on the remote systems appear as part of your local filesystem, and all the utilities you use for listing and managing files (e.g., ls, cp, mv) operate on the remote files exactly as they do on your local files.
This filesystem allows the same characters in a filename as the Power-Safe filesystem; see “Power-Safe filesystem,” earlier in this chapter.
It's actually the clients that do the work required to convert the generalized file access that servers provide into a file access method that's useful to applications and users.
An NFS server handles requests from NFS clients that want to access filesystems as NFS mountpoints. For the server to work, you need to start the following programs:
The rpcbind server maps RPC program/version numbers into TCP and UDP port numbers. Clients can make RPC calls only if rpcbind is running on the server.
The nfsd daemon reads the /etc/exports file, which lists the filesystems that can be exported and optionally specifies which clients those filesystems can be exported to. If no client is specified, any requesting client is given access.
The nfsd daemon services both NFS mount requests and NFS requests, as specified by the exports file. Upon startup, nfsd reads the /etc/exports.hostname file (or, if this file doesn't exist, /etc/exports) to determine which mountpoints to service. Changes made to this file don't take affect until you restart nfsd.
An NFS client requests that a filesystem exported from an NFS server be grafted onto its local namespace. For the client to work, you need to first start the version 2 or 3 of the NFS filesystem manager (fs-nfs2 or fs-nfs3). The file handle in version 2 is a fixed-size array of 32 bytes. With version 3, it's a variable-length array of 64 bytes.
The fs-nfs2 or fs-nfs3 filesystem manager is also the NFS 2 or NFS 3 client daemon operating over TCP/IP. To use it, you must have an NFS server and you must be running a TCP/IP transport layer such as that provided by io-pkt*. It also needs socket.so and libc.so.
You can create NFS mountpoints with the mount command by specifying nfs for the type and -o ver3 as an option. You must start fs-nfs3 or fs-nfs3 before creating mountpoints in this manner. If you start fs-nfs2 or fs-nfs3 without any arguments, it runs in the background so you can use mount.
To make the request, the client uses the mount utility, as in the following examples:
mount -t nfs 10.1.0.22:/home /mnt/home
mount -t nfs -o ver3 server_node:/qnx_bin /bin
In the first example, the client requests that the /home directory on an IP host be mounted onto the local namespace as /mnt/home. In the second example, NFS protocol version 3 is used for the network filesystem.
Here's another example of a command line that starts and mounts the client:
fs-nfs3 10.7.0.197:/home/bob /homedir