There is a certain habit in shell scripts of referring to uncommonprograms by their absolute path; for example, if you need to run lsof ,people will write ' /usr/sbin/lsof .... ' in their shell script. Wedo a certain amount of that here, and then recently one of our shellscripts started reporting:

netwatch: line 15: /usr/sbin/lsof: No such file or directory

You see, you shouldn't do this, because every so often

Roughly speaking, there's two sorts of access restrictions that an NFSserver can put on a client: what filesystems the client can access,and what directories in the filesystems the client can access (this isnecessary when you export a subdirectory in the filesystem, instead ofthe whole filesystem).

(This ignores just firewalling off the client entirely. The NFS servercode generally doesn't have any special handling for this, because fromits perspective, not allowing someone to talk at all is functionallyidentical to not

In the beginning, NFS servers had no access restrictions. No, really.

In the early versions of NFS, the kernel NFS code had no access checks;if you had a valid filehandle , the kernelwas happy to talk to you, regardless of who you were. What NFS accessrestrictions existed were all done during the NFS mount process ; if you were not authorized to mount the particular thingyou were asking for, mountd would not give you a filehandle forit. This was, of course, secure only

Now that we know what goes on in NFS mounts , wecan see that there are any number of moving parts that can go wrong:

• the RPC portmapper refuses to talk to you (possibly because a firewallgets in the way, possibly because it has been set up with tcpwrappersbased restrictions).
• the NFS mount daemon refuses to talk to you, possibly because itusually insists that clients use a reserved port , or there could be another firewallproblem since it uses a different port than the portmapper.

• the NFS mount