The CLN will export any filesystems configured in the /etc/exports
file. Here is an example of a line in /etc/exports that tells the
CLN to export a filesystem mounted on /mnt/alpha.
/mnt/alpha 205.185.197.207(rw,sync,no_root_squash,fsid=20)
The line tells the CLN to make the filesystem available via NFS to the
host with the IP address 205.185.197.207. NFS provides security based
on access granted in /etc/exports and based on user identity.
Presumably, the network is secure enough that we know this IP
corresponds to a particular host, and the users on host are managed by
an authorized system administrator.
If you have a trusted network, you can open up NFS even more by specifying a network instead of one or more IP addresses. The example below uses a 24-bit netmask to allow any IP starting with "205.185.197." to access the exported filesystem.
/mnt/alpha 205.185.197.0/24(rw,sync,no_root_squash,fsid=20)
Between the parentheses, the line includes options to control the way the filesystem is exported. In this example, the CLN is on a trusted storage network, so client access is liberal.
rw option says to export the filesystem such that clients can
read and write to it.
sync option is safest for data, because writes are pushed out
to persistent storage before telling the client that the write has
finished. The async option results in higher performance but
carries increased danger of data corruption, e.g., on power
failure.
no_root_squash option means that the root user on any NFS
client maintains root privileges when accessing files on the
exported filesystem. This setting is practical on a dedicated
storage network where all hosts on the network are controlled by
legitimate system administrators.
fsid=20 option provides a number to use in identifying the
filesystem. This number must be different for all the filesystems
in /etc/exports that use the fsid option. This option is only
necessary for exporting filesystems that reside on a block device
with a minor number above 255, as shown by ls -l. For exmample,
AoE devices with a shelf address above zero have devices large minor
numbers.
These options are documented in the manpage for the /etc/exports
file.
makki:~# man exports
After changing the /etc/exports file, run exportfs -ra. This
command tells the running NFS server to re-read /etc/exports.
makki:~# exportfs -ra
On kokone, the host with IP 205.185.197.207, we can now mount and
use the exported filesystem using NFS.
root@kokone ~# mount -t nfs makki:/mnt/alpha /mnt/makki root@kokone ~# rsync -a /usr/share/doc/ruby1.8 /mnt/makki root@kokone ~# ls /mnt/makki/ruby1.8/ COPYING NEWS.Debian.gz README.Debian changelog.Debian.gz COPYING.ja NEWS.gz README.ja changelog.gz LEGAL.gz README ToDo.gz copyright root@kokone root#
Any other host in the 205.185.197.0 network can also mount and use the exported filesystem at the same time.
If kokone is connected to makki by a lossy network, doing NFS over
TCP may result in better performance. The tcp mount option
specifies that the client would like to use TCP for NFS.
Solaris 10 NFS clients might need to configure the client not to use
NFS v4 when mounting volumes from the CLN. Solaris 10 users report
that adding a line like the one below to the /etc/auto_master file
on the NFS client eliminated "not owner" errors.
/home auto_home -nobrowse,vers=3
An alternative would be to set up NFS v4 on the CLN. NFS v4 is not officially supported on the CLN, but the framework exists for those who would like to be early adopters.