Ø If you want to provide NFS service to other hosts, you have to run the nfsd and mountd daemons on your machine. As RPC-based programs, they are not managed by inetd, but are started up at boot time, and register themselves with the portmapper. Therefore, you have to make sure to start them only after rpc.portmap is running. Usually, you include the following two lines in your rc.inet2 script:
if [ -x /usr/sbin/rpc.mountd ]; then
/usr/sbin/rpc.mountd; echo -n " mountd"
fi
if [ -x /usr/sbin/rpc.nfsd ]; then
/usr/sbin/rpc.nfsd; echo -n " nfsd"
Fi
Ø The ownership information of files a NFS daemon provides to its clients usually contains only numerical user and group id's. If both client and server associate the same user and group names with these numerical id's, they are said to share the same uid/gid space. For example, this is the case when you use NIS to distribute the passwd information to all hosts on your LAN.
Ø On some occasions, however, they do not match. Rather updating the uid's and gid's of the client to match those of the server, you can use the ugidd mapping daemon to work around this. Using the map_daemon option explained below, you can tell nfsd to map the server's uid/gid space to the client's uid/gid space with the aid of the ugidd on the client.
ugidd is an RPC-based server, and is started from rc.inet2 just like nfsd and mountd.
if [ -x /usr/sbin/rpc.ugidd ]; then
/usr/sbin/rpc.ugidd; echo -n " ugidd"
fi
Ø While the above options applied to the client's NFS configuration, there is a different set of options on the server side that configure its per-client behavior. These options must be set in the /etc/exports file.
Ø By default, mountd will not allow anyone to mount directories from the local host, which is a rather sensible attitude. To permit one or more hosts to NFS-mount a directory, it must exported, that is, must be specified in the exports file. A sample file may look like this:
# exports file for vlager
/home vale(rw) vstout(rw) vlight(rw)
/usr/X386 vale(ro) vstout(ro) vlight(ro)
/usr/TeX vale(ro) vstout(ro) vlight(ro)
/ vale(rw,no root squash)
/home/ftp (ro)
Ø The host name is followed by an optional, comma-separated list of flags, enclosed in brackets. These flags may take the following values:
insecure
Permit non-authenticated access from this machine.
unix-rpc
Require UNIX-domain RPC authentication from this machine. This simply requires that requests originate from a reserved internet port (i.e. the port number has to be less than 1024). This option is on by default.
secure-rpc
Require secure RPC authentication from this machine. This has not been implemented yet. See Sun's documentation on Secure RPC.
kerberos
Require Kerberos authentication on accesses from this machine. This has not been implemented yet. See the MIT documentation on the Kerberos authentication system.
root squash
This is a security feature that denies the super user on the specified hosts any special access rights by mapping requests from uid 0 on the client to uid 65534 (-2) on the server. This uid should be associated with the user nobody.
no root squash
Don't map requests from uid 0. This option is on by default.
ro
Mount file hierarchy read-only. This option is on by default.
rw
Mount file hierarchy read-write.
link relative
Convert absolute symbolic links (where the link contents start with a slash) into relative links by prepending the nec- essary number of ../'s to get from the directory containing the link to the root on the server. This option only makes sense when a host's entire file system is mounted, else some of the links might point to nowhere, or even worse, files they were never meant to point to.
Ø and transparently mounts any NFS volume as needed, and unmounts them after they have not been used for some time.
Ø One of the clever things about an automounter is that it is able to mount a certain volume from alternative places. For instance, you may keep copies of your X-programs and support files on two or three hosts, and have all other hosts mount them via NFS. Using an automounter, you may specify all three of them to be mounted on /usr/X386; the automounter will then try to mount any of these until one of the mount attempts succeeds.
