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
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:
For a complete description of these filesystem types, see
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.
Acer Fast filesystem
(includes the HS, ISO-9600,
Joliet, and Rockridge CD-ROM filesystems)
Extended Acer Fast filesystem
High throughput filesystem
High performance, volatile memory filesystem
AT&T UNIX System V 1KB filesystem
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
If rcmount=prompt is specified, the system queries for
instructions and only mounts the remote filesystem if it receives a positive
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
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''.
Mounting filesystems from remote hosts can incur security risks.
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:
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
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
NFS server and client daemons
How NFS works
© 2005 The SCO Group, Inc. All rights reserved.
SCO OpenServer Release 6.0.0 -- 02 June 2005