Managing NFS and NIS, 2nd Edition - Mike Eisler [68]
server% ps -e | grep -w mountd
274 ? 0:00 mountd
server% ps -e | grep -w rpcbind
106 ? 0:00 rpcbind
You should see both the mountd and the rpcbind processes running on the NFS server.
If mount promptly reports "Program not registered," this means that the mountd daemon never started up and registered itself. In this case, make sure that mountd is getting started at boot time on the NFS server, by checking the /etc/dfs/dfstabfile. See Section 6.1 earlier in this chapter.
Another mountd-related problem is two mountd daemons competing for the same RPC service number. On some systems (not Solaris), there might be a situation when one mount daemon can be started in the boot script and one configured into /etc/inet/inetd.conf; the second instance of the server daemon will not be able to register its RPC service number with the portmapper. Since the inetd-spawned process is usually the second to appear, it repeatedly exits and restarts until inetd realizes that the server cannot be started and disables the service. The NFS RPC daemons should be started from the boot scripts and not from inetd, due to the overhead of spawning processes from the inetd server (see Section 1.5.3).
There is also a detection mechanism for attempts to make "transitive," or multihop, NFS mounts. You can only use NFS to mount another system's local filesystem as one of your NFS filesystems. You can't mount another system's NFS-mounted filesystems. That is, if /export/home/bob is local on serverb, then all machines on the network must mount /export/home/bob from serverb. If a client attempts to mount a remotely mounted directory on the server, the mount fails with a multihop error message. Let's say NFS client marble has done:
# mount serverb:/export/home/bob /export/home/bob
and marble is also an NFS server that exports /export/home. If a third system tries to mount marble:/export/home/bob, then the mount fails with the error:
mount: marble:/export/home/bob on /users/bob: Too many levels of remote in path
"Too many levels" means more than one — the filesystem on the server is itself NFS-mounted. You cannot nest NFS mounts by mounting through an intermediate fileserver. There are two practical sides to this restriction:
Allowing multihop mounts would defeat the host-based permission checking used by NFS. If a server limits access to a filesystem to a few clients, then one of these client should not be allowed to NFS-mount the filesystem and make it available to other, non-trusted systems. Preventing multihop mounts makes the server owning the filesystem the single authority governing its use — no other machine can circumvent the access policies set by the NFS server owning a filesystem.
Any machine used as an intermediate server in a multihop mount becomes a very inefficient "gateway" between the NFS client and the server owning the filesystem.
We've seen how to export NFS filesystems on a network and how NFS clients mount them. With this basic explanation of NFS usage, we'll look at how NFS mounts are combined with symbolic links to create more complex — and sometimes confusing — client filesystem structures.
Symbolic links
Symbolic links are both useful and confusing when used with NFS-mounted filesystems. They can be used to "shape" a filesystem arbitrarily, giving the system administrator freedom to organize filesystems and pathnames in convenient ways. When used badly, symbolic links have unexpected and unwanted side effects, including poor performance and "missing" files or directories. In this section, we'll discuss the many effects that symbolic links can have on NFS.
Symbolic links differ from hard links in several ways, but the salient distinction is that hard links duplicate directory entries, while