DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
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:


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:



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.

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

© 2005 The SCO Group, Inc. All rights reserved.
SCO OpenServer Release 6.0.0 -- 02 June 2005