Subscribe

CIFS Shares on Data ONTAP 8.01-7-Mode Lag in Effective Rights

Hi,

I am experiencing a long lag for effective rights to be enforced on CIFS connected to Active Directory 2008 Domain. When I change the rights from  Read to Full Control as shown below it takes a very long time (hours) to be enforced. With very little data and files contained within the qtree as this is just a POC within the environment. Eventually it works and the user does not get Denied access/permission errors etc. According to the documents it should be immediate. The goal is to remove everyone Read and just have Active Directory groups(member_of_group) control the access through Share Permissions only and not NTFS to keep things simple.

Note: Windows clients only XP/2003/2008.

https://library.netapp.com/ecmdocs/ECMM1278309/html/cmdref/man1/na_cifs_access.1.htm.

cifs shares jeff1

Name         Mount Point                       Description

----         -----------                       -----------

jeff1        /vol/jeffshare/jeff               Created on 01/08/2012

                        everyone / Read

                        Domain-JG\TeamJG / Full Control

qtree info:

qtree status jeffshare

Volume   Tree     Style Oplocks  Status

-------- -------- ----- -------- ---------

jeffshare          unix  enabled  normal

jeffshare jeff     unix  enabled  normal

Any ideas on what is causing this?

Thanks

Jeff

Re: CIFS Shares on Data ONTAP 8.01-7-Mode Lag in Effective Rights

If this data is only accessed over NTFS then I would be using NTFS security style on the volume/qtree rather than unix.

Pure speculation here but some things to check if you are out of ideas:

I would check the DNS setup is healthy and there are not timeout's to the DNS servers or DC's. Make sure you are hitting local servers if this is a large enterprise and make sure the DC you are contacting has received any replicated amendments to the group before you test. If the controllers IP's are not in a range defined in a local AD site they may be hitting DC's anywhere in the domain and timing out authentication checks.

After you change the permissions have you tried log off/log on of the user account to see if you get immediate rights update?

If you add a local user with Full Control and access the share with that do you get immediate permission update?

Re: CIFS Shares on Data ONTAP 8.01-7-Mode Lag in Effective Rights

The first obvious answer - share ACL change does not affect existing sessions. So users who were connected before remain connected until something forces them to reconnect.

Share ACLs are much less granular and flexible than file ACLs, and Microsoft actually recommends exactly opposite - leave share open and control permissions on filesystem level.

Re: CIFS Shares on Data ONTAP 8.01-7-Mode Lag in Effective Rights

Hi,

There were no existing sessions. This was a test share so the user sessions were only my test accounts which I logged out each time.

Jeff

Re: CIFS Shares on Data ONTAP 8.01-7-Mode Lag in Effective Rights

Hi,

a) Local User - Yes works like a charm.

cifs shares jeff1

Name         Mount Point                       Description

----         -----------                       -----------

jeff1        /vol/jeffshare/jeff               Created on 01/08/2012

                        everyone / Read

                        Domain-JG\TeamJG / Full Control

                        filer02\user1 / Full Control

b) I am seeing this error in the message logs every 10-30 minutes:

Fri Sep  7 07:11:00 EDT [filer02: ddns_loop:info]: Lookup of filer02.domain.local failed with DNS server 10.141.236.25: Input/output error.

[ checking DNS -> nslookup, ping and ping -a; all resolve properly from a client; so I think that is a Red Herring]

dns info

DNS is enabled

DNS caching is enabled

15099 cache hits

11103 cache misses

58 cache entries

10880 expired entries

10789 cache replacements

IP Address                                     State   Last Polled                  Avg RTT Calls  Errs

-------------------------------------------------------------------------------------------------------------

10.141.236.25                                  UP      Fri Sep  7 09:51:10 EDT 2012       7 138312  2598

c) The reason for this test is that all the current volumes are Unix style and there maybe Linux in the near future accessing those shares.

Thanks

Jeff