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

Here is something that we discovered recently: ZFS will refuse toscrub a pool that is DEGRADED , even if the degraded state is harmlessto actual pool redundancy and there is no resilvering going on. In theusual ZFS manner, it doesn't give you any actual errors, it just doesn'tdo anything when you ask for a pool scrub.

(Now, I can't be completely and utterly sure that it was the DEGRADEDstate that blocked the scrub and not coincidence or somethingunrelated. But I