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.
By "spontaneously," I mean that /etc/log/auditlog and our homegrown API-based tool confirm that there were no filer configuration changes made.
The FlexVol and qtrees are all ntfs mode. The "hidden qtree" 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.
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.
Share permissions are basic:
Name Mount Point Description ---- ----------- ----------- General /vol/general General public share everyone / Change BUILTIN\Administrators / Full Control DAYJOB\Domain Admins / Full Control
If we use "Previous versions" on Windows to access the 12p snapshot yesterday, the qtrees are all visible. Using "cacls" or the "Security" tab to view permissions on both hidden and visible directories shows nothing unexpected - and no changes in permissions relative to the 12p snapshot.
A "cifs terminate"/"cifs restart" 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.
I'd be grateful for any ideas anyone here might have.
Thanks, Andy
This could be BURT 433420. I had a customer just report a very similar issue
Sent from my iPhone 5
On Dec 8, 2012, at 7:39 AM, "Andrew Leonard" lists@hurricane-ridge.com wrote:
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.
By "spontaneously," I mean that /etc/log/auditlog and our homegrown API-based tool confirm that there were no filer configuration changes made.
The FlexVol and qtrees are all ntfs mode. The "hidden qtree" 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.
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.
Share permissions are basic:
Name Mount Point Description
General /vol/general General public share everyone / Change BUILTIN\Administrators / Full Control DAYJOB\Domain Admins / Full Control
If we use "Previous versions" on Windows to access the 12p snapshot yesterday, the qtrees are all visible. Using "cacls" or the "Security" tab to view permissions on both hidden and visible directories shows nothing unexpected - and no changes in permissions relative to the 12p snapshot.
A "cifs terminate"/"cifs restart" 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.
I'd be grateful for any ideas anyone here might have.
Thanks, Andy _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Thanks, Scott.
If I'm reading that BURT correctly, NFS and CIFS follow different paths to look up data set identifiers, perhaps explaining why our NFS clients can still see the qtrees. (I assume VLDB is an ONTAP-internal volume database.)
I'm hoping a forced upgrade to 8.1 isn't going to be the only solution, given the performance concerns with 8.1 raised elsewhere.
Thanks, Andy
On Sat, Dec 8, 2012 at 9:39 AM, Gelb, Scott sgelb@insightinvestments.comwrote:
This could be BURT 433420. I had a customer just report a very similar issue
Sent from my iPhone 5
On Dec 8, 2012, at 7:39 AM, "Andrew Leonard" lists@hurricane-ridge.com wrote:
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.
By "spontaneously," I mean that /etc/log/auditlog and our homegrown
API-based tool confirm that there were no filer configuration changes made.
The FlexVol and qtrees are all ntfs mode. The "hidden qtree" 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.
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.
Share permissions are basic:
Name Mount Point Description
General /vol/general General public share everyone / Change BUILTIN\Administrators / Full Control DAYJOB\Domain Admins / Full Control
If we use "Previous versions" on Windows to access the 12p snapshot
yesterday, the qtrees are all visible. Using "cacls" or the "Security" tab to view permissions on both hidden and visible directories shows nothing unexpected - and no changes in permissions relative to the 12p snapshot.
A "cifs terminate"/"cifs restart" 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.
I'd be grateful for any ideas anyone here might have.
Thanks, Andy _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-
Andrew Leonard -
Gelb, Scott