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

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

DRUMDUDESAN — Thu, 05 Jun 2025 06:19:31 GMT

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

dominicb — Fri, 07 Sep 2012 01:08:33 GMT

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

aborzenkov — Fri, 07 Sep 2012 02:45:45 GMT

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

DRUMDUDESAN — Fri, 07 Sep 2012 11:59:38 GMT

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

DRUMDUDESAN — Fri, 07 Sep 2012 13:52:35 GMT

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