Yesterday afternoon around 2p local time, a CIFS share of a FlexVol containing multiple qtree spontaneously began hiding the qtrees within the share (filer is running 8.0.2P3 7-Mode): At the root of the share, non-qtree directories are still visible; qtrees are no longer visible.  However, if a user enters the path to the qtree manually, they can access a hidden qtree and files beneath it.  <div>
<br></div><div>By &quot;spontaneously,&quot; I mean that /etc/log/auditlog and our homegrown API-based tool confirm that there were no filer configuration changes made.<div><br></div><div><div>The FlexVol and qtrees are all ntfs mode.  The &quot;hidden qtree&quot; behavior has been seen on SMB connections from Windows 7, w2k3 and OS X (at least 10.8, probably other versions).  We also share this FlexVol to NFS clients, although usage is light.  NFS clients can see and access all qtrees as usual.</div>
<div><br></div><div>There were a couple of initial reports from OS X users that they could not connect to the share at all, although I could not confirm or replicate this myself.</div><div><br></div><div>Share permissions are basic:</div>
<div><br></div><div><div><div>Name         Mount Point                       Description</div><div>----         -----------                       -----------</div><div>General      /vol/general                      General public share</div>
<div><span class="" style="white-space:pre">			</span>everyone / Change</div><div><span class="" style="white-space:pre">			</span>BUILTIN\Administrators / Full Control</div><div><span class="" style="white-space:pre">			</span>DAYJOB\Domain Admins / Full Control</div>
</div><div><div><br></div><div><div>If we use &quot;Previous versions&quot; on Windows to access the 12p snapshot yesterday, the qtrees are all visible.  Using &quot;cacls&quot; or the &quot;Security&quot; tab to view permissions on both hidden and visible directories shows nothing unexpected - and no changes in permissions relative to the 12p snapshot.</div>
<div><br></div><div>A &quot;cifs terminate&quot;/&quot;cifs restart&quot; requested by NetApp support did not resolve the issue; they continue to work on it, but assert that they have never seen anything like it before.  </div>
<div><br></div><div>I&#39;d be grateful for any ideas anyone here might have.</div></div></div><div><br></div><div>Thanks,</div><div>Andy</div></div></div></div>