Configuring the Network File System (NFS)

Distributed filesystems

A distributed filesystem uses the client-server model to provide shared access to files across a network. Servers export (make available) directories of files residing on their storage media, and clients can mount (gain access to) directories that have been exported.

About exporting and importing filesystems

NFS uses the term ``exporting'' to define the process of a server machine making local directories of files available to remote systems. Files available for access by remote systems are said to be exported. Similarly, but not used as frequently, NFS uses the term ``importing'' to define the process of a client machine requesting access to the exported files on a server. More commonly, this process is referred to as ``mounting'' a filesystem.

Filesystems supported by SCO NFS

You can export the following filesystems via NFS:

AFS: Acer Fast filesystem
cdfs: CD-ROM filesystem (includes the HS, ISO-9600, Joliet, and Rockridge CD-ROM filesystems)
dosfs: DOS filesystem
EAFS: Extended Acer Fast filesystem
HTFS: High throughput filesystem
memfs: High performance, volatile memory filesystem
S51K: AT&T UNIX System V 1KB filesystem

For a complete description of these filesystem types, see mount(ADM). Once a filesystem has been NFS-exported by an NFS server, an NFS client sees the filesystem as type NFS and may therefore mount that filesystem irrespective of its actual type.

About mounting and unmounting NFS filesystems

A client can mount a filesystem in four different ways:

automatic mounting at system start: The system administrator of a client machine can configure the client to automatically mount remote filesystems every time the client machine goes to multiuser mode. Each remote filesystem to be mounted at this time must have an entry in the /etc/default/filesys file of the client. The entry must include the option rcmount=yes or rcmount=prompt. If rcmount=prompt is specified, the system queries for instructions and only mounts the remote filesystem if it receives a positive response. Remote filesystems mounted because of an entry in /etc/default/filesys are unmounted when the system goes to single-user mode.
administrator manual mounting: The system administrator of a client machine can manually mount remote filesystems at any time using the mount(ADM) command.
user mounting: The system administrator of a client machine can authorize users to mount remote filesystems when they need access to them. See ``Enabling users to mount filesystems''.
automounting: A client machine can be configured to automatically mount remote filesystems when a user executes a command requiring access to those files. The mounted filesystems remain mounted until a preset period of inactivity has passed. At this point the client automatically unmounts them. See ``How automount works''.

CAUTION: Mounting filesystems from remote hosts can incur security risks. See ``Imported data'' for more information.

Incompatibilities with distributed filesystems

A few things work in unexpected ways, or not at all, on distributed NFS filesystems:

File operations not supported

File locking operations on directories are not supported on remote filesystems.

Append mode and atomic writes are not guaranteed to work on remote files accessed by more than one client simultaneously. NFS does not support mandatory file locking for remote filesystems. Only advisory file-locking is available over the network; applications fail if they rely on mandatory locking of remote files over the network. Some resultant limitations:

The locking(S) system call uses mandatory file locking, and therefore fails when the files to be locked are on remote filesystems.
SCO Integra^® uses mandatory file locking, and therefore fails when used with remote files.

Cannot access remote devices

With NFS, it is not possible to access a remote-mounted device or any other character or block-special file.

Cannot access indirect filesystems

Under NFS, it is not possible to access a filesystem indirectly. For example, you may not use a server machine to access a filesystem on a third server machine. All NFS access must be direct from server to client.

Cannot access server inodes

If an NFS client running SCO^® Open Desktop^® Release 3.0 or earlier tries to mount filesystems from an SCO OpenServer Release 5 NFS server, some of the exported files may not be available. This is because SCO OpenServer filesystems such as HTFS support a greater number of inodes (2^32) than filesystems in earlier releases (2^16). We recommend that the number of inodes in a server's exported filesystem should not exceed the maximum number that a client can address.