When a change is made to an export policy in clustered Data ONTAP, the export policy access cache is flushed and needs to be re-populated.
If there are issues re-populating the cache, access could be denied in those scenarios. If there are a large number of policies/rules/clients, then repopulating the cache could cause an RPC storm to the cluster management gateway or to name services like DNS and cause a denial of service scenario.
If you were to remove a client from a policy, that client would no longer have access to the export. This is by design.
TR-4067 covers export policies and rules in detail and describes some best practices for exports in cDOT.
http://www.netapp.com/us/media/tr-4067.pdf
Additionally, I am working on a name services best practice guide to cover this.
If you are on 8.2.x now, I'd highly recommend moving to 8.2.2P2 in the immediate future, as there are a number of fixes to avoid these types of problems, such as this one. Then as soon as 8.2.3 is available, upgrade. That is the recommended 8.2.x release for NFS exports.
http://mysupport.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=843089
http://mysupport.netapp.com/NOW/download/software/ontap/8.2.2P2/
Also, if you are using IP addresses, I'd recommend ensuring those IP addresses have reverse lookup records (PTR) in DNS if possible. If that's not possible, then add the ESX servers to DNS hosts on the cluster.
::> dns hosts create -vserver [cluster vserver]
In 8.2 and earlier, this would be done at the cluster vserver. In 8.3 and later, do this at the data vserver.