我们有一堆安装了NetApp文件pipe理器的NFS共享的Linux机器。 不时，我会flub一些部分的出口configuration。 在其中一个允许的主机上输错，IP地址不正确等等。不用担心，这通常是在testing系统上完成的，或者是在尚未投入生产的全新出口的情况下完成的。
但是，我发现一旦我被拒绝从Linux机器上挂载某个东西的权限，失败就会被caching一天。 我将更正阻止挂载的问题，在NetApp上重新导出，但仍然无法挂载共享。 我很确定这个caching是在NetApp方面完成的。 它通常在一天左右后衰老，但真的很糟糕，不得不等到明天才能上股。
我已经尝试了NetApp上的exportfs -f以及dns flush 。 （我通过Google发现了这两个build议）但是，两者都无法正常工作。
如果有人能帮助解决caching问题的命令/异教仪式，我会卖掉我的灵魂。
您可以运行“exportfs”而不用任何选项来validation您的导出是否正确加载。 如果它位于/ etc / exports文件中但未加载，则可能需要“exportfs -a”或“exportfs -r”将其重新导出。 从那里你可以用“exportfs -c”来检查访问caching，或者使用“exportfs -f”来清除它。
接下来要检查控制器是你的客户端可以访问和parsing。 假设您的networking上启用了ping，则可以从NetApp控制器“ping -s主机名”。 我会检查主机名和IP地址。
过去，你可能需要看看你的客户。
那么，这应该不会发生，假设你正在重新加载出口正确（即不只是更新/ etc / exports。首先要做的是打开日志选项的挂载请求：
options nfs.mountd.trace on
然后检查/ etc / messages，看看你看到了什么。 如果不是很明显，请更新输出，我们可以看看更多。 有太多的其他因素在这里试图诊断没有更多的信息。
通常flush -f工作，但今天我不得不包括-n（OnTap 7.3.7P1） – 观察结果与选项nfs.response.trace和nfs.mountd.trace
当导出错误并且需要清除并加载新的时，首先从NetApp Exports中修复它，然后从客户端在Linux节点上运行“Service nfslock restart”。
希望这有助于未来的人。