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