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.

See also:

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:

Acer Fast Filesystem

DOS filesystem

Desktop filesystem

Extended Acer Fast Filesystem

High Sierra CD-ROM Filesystem

High throughput filesystem

ISO 9660 CD-ROM filesystem

SCO Gateway for NetWare filesystem

Rockridge CD-ROM filesystem

AT&T UNIX System V 1KB filesystem

XENIX 286/386 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''.

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:

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 DTFS and 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.

Next topic: NFS server and client daemons
Previous topic: How NFS works

© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003