up | Inhaltsverzeichniss | Kommentar

Manual page for NFS(4P)

nfs, NFS - network file system


options NFS


The Network File System, or NFS, allows a client workstation to perform transparent file access over the network. Using it, a client workstation can operate on files that reside on a variety of servers, server architectures and across a variety of operating systems. Client file access calls are converted to NFS protocol requests, and are sent to the server system over the network. The server receives the request, performs the actual file system operation, and sends a response back to the client.

The Network File System operates in a stateless fashion using remote procedure (RPC) calls built on top of external data representation (XDR) protocol. These protocols are documented in [a manual with the abbreviation NETP] The RPC protocol provides for version and authentication parameters to be exchanged for security over the network.

A server can grant access to a specific filesystem to certain clients by adding an entry for that filesystem to the server's /etc/exports file and running exportfs.8

A client gains access to that filesystem with the mount.2v system call, which requests a file handle for the filesystem itself. Once the filesystem is mounted by the client, the server issues a file handle to the client for each file (or directory) the client accesses or creates. If the file is somehow removed on the server side, the file handle becomes stale (dissociated with a known file).

A server may also be a client with respect to filesystems it has mounted over the network, but its clients cannot gain access to those filesystems. Instead, the client must mount a filesystem directly from the server on which it resides.

The user ID and group ID mappings must be the same between client and server. However, the server maps uid 0 (the super-user) to uid -2 before performing access checks for a client. This inhibits super-user privileges on remote filesystems. This may be changed by use of the ``anon'' export option. See exportfs.8

NFS-related routines and structure definitions are described in [a manual with the abbreviation NETP].


Generally physical disk I/O errors detected at the server are returned to the client for action. If the server is down or inaccessible, the client will see the console message:

NFS server host not responding still trying.
Depending on whether the file system has been mounted ``hard'' or ``soft'' (see mount.8 the client will either continue (forever) to resend the request until it receives an acknowledgement from the server, or return an error to user-level. For hard mounts, this means the server can crash or power down and come back up without any special action required by the client. If the ``intr'' mount option was not specified, a client process requesting I/O will block and remain insensitive to signals, sleeping inside the kernel at PRIBIO until the request is satisfied.




mount.2v exports.5 fstab.5 fstab.5 exportfs.8 mount.8 nfsd.8 sticky.8

[a manual with the abbreviation NETP]


When a file that is opened by a client is unlinked (by the server), a file with a name of the form .nfsXXX (where XXX is a number) is created by the client. When the open file is closed, the .nfsXXX file is removed. If the client crashes before the file can be closed, the .nfsXXX file is not removed.

NFS servers usually mark their clients' swap files specially to avoid being required to sync their inodes to disk before returning from writes. See sticky.8

index | Inhaltsverzeichniss | Kommentar

Created by unroff & hp-tools. © by Hans-Peter Bischof. All Rights Reserved (1997).

Last modified 21/April/97