<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic NFS Export Policy Issue in Network and Storage Protocols</title>
    <link>https://community.netapp.com/t5/Network-and-Storage-Protocols/NFS-Export-Policy-Issue/m-p/101575#M7617</link>
    <description>&lt;P&gt;I've unfortunately discovered the following related to export polices. &amp;nbsp;If your export policy contains rules specific to a hostname that no longer resolves in your DNS...the next time a change is applied to that export-policy OR in my case, you perform a takeover in the midst of an NDU to a newer version of CDOT...the export policy fails to function.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;So basically, all VALID hostnames in the export policy lose access to the mount. &amp;nbsp;Then as soon as you remove the offending rules from the export policy, access to the mount resumes on the valid hosts defined.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;The symptom from the NFS client is all access being halted w/ a busy NFS mount status. &amp;nbsp;For example, simply running an 'ls' command on the mount halts your console activity indefinitely and it will free back up as soon as you delete the offending rules.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;This is repeatable for me and I'm currently running version CDOT 8.2.3 on our FAS cluster.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Anyone else had this occur? &amp;nbsp;What are thoughts on this behavior? &amp;nbsp;I personally feel this is a BAD thing even though it does protect the security of the export. &amp;nbsp;It would have been a horrible story to tell if this had happened to a volume we use for our VMware NFS datastores.&lt;/P&gt;</description>
    <pubDate>Thu, 05 Jun 2025 04:54:56 GMT</pubDate>
    <dc:creator>bsnyder27</dc:creator>
    <dc:date>2025-06-05T04:54:56Z</dc:date>
    <item>
      <title>NFS Export Policy Issue</title>
      <link>https://community.netapp.com/t5/Network-and-Storage-Protocols/NFS-Export-Policy-Issue/m-p/101575#M7617</link>
      <description>&lt;P&gt;I've unfortunately discovered the following related to export polices. &amp;nbsp;If your export policy contains rules specific to a hostname that no longer resolves in your DNS...the next time a change is applied to that export-policy OR in my case, you perform a takeover in the midst of an NDU to a newer version of CDOT...the export policy fails to function.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;So basically, all VALID hostnames in the export policy lose access to the mount. &amp;nbsp;Then as soon as you remove the offending rules from the export policy, access to the mount resumes on the valid hosts defined.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;The symptom from the NFS client is all access being halted w/ a busy NFS mount status. &amp;nbsp;For example, simply running an 'ls' command on the mount halts your console activity indefinitely and it will free back up as soon as you delete the offending rules.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;This is repeatable for me and I'm currently running version CDOT 8.2.3 on our FAS cluster.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Anyone else had this occur? &amp;nbsp;What are thoughts on this behavior? &amp;nbsp;I personally feel this is a BAD thing even though it does protect the security of the export. &amp;nbsp;It would have been a horrible story to tell if this had happened to a volume we use for our VMware NFS datastores.&lt;/P&gt;</description>
      <pubDate>Thu, 05 Jun 2025 04:54:56 GMT</pubDate>
      <guid>https://community.netapp.com/t5/Network-and-Storage-Protocols/NFS-Export-Policy-Issue/m-p/101575#M7617</guid>
      <dc:creator>bsnyder27</dc:creator>
      <dc:date>2025-06-05T04:54:56Z</dc:date>
    </item>
  </channel>
</rss>

