Network and Storage Protocols

Random "access denied" while connecting to CIFS shares



I've a strange issue for a few days. Issue occurs since i've dcpromo'ed 2 new DC's Windows 2012 servers in my Windows Server 2008 R2 AD domain.

And now, sometimes, after a reboot+login, one (and only one) of the 6 CIFS shares (hosted on filer) is browsable on user's desktops. I've an "access denied" msgbox on other mapped shares. I reboot, and then, i becomes accessible.. or not, so i reboot until it finally works.

I first thought that it was %LOGONSERVER%-dependant. Although it seems more frequent when %LOGONSERVER% is one of the W2012 DC, it's not always the case (it's working sometimes).

I didn't change any NTFS ACL / share permissions since W2012 DC installation.

  • NetApp Release 8.0.2P3 7-Mode
  • Volumes / qtrees are NTFS only.  Access-based enumeration is ON.

I've looked on SMB side, but, even when access is denied, net view \\filer shows correctly each share.

SMB 2.0 is active on clients, DCs and filer. But signing is not required on both sides.

cifs.smb2.client.enable      on

cifs.smb2.durable_handle.enable on

cifs.smb2.durable_handle.timeout 10m

cifs.smb2.enable             on

cifs.smb2.signing.required   off

Nothing relevant when cifs.trace_dc_connection or cifs.trace_login are ON :

[filer : auth.trace.authenticateUser.loginTrace:info]: AUTH: Login attempt by user test2 of domain DOMAIN from client machine

[filer : auth.trace.spnegoAuthentication.statusMsg:info]: AUTH: SPNEGO- Attempting to map PC user to UNIX user test2.

[filer : auth.trace.mapNTToUnix:info]: AUTH: Mapping Windows user test2 to Unix user pcuser.

[filer : auth.trace.authenticateUser.loginAccepted:info]: AUTH: Login by test2 from accepted.

sectrace from client when accessing share :

Tue Mar 12 11:14:37 CET [filer: sectrace.filter.denied:info]: [sectrace index: 1] Access denied because 'Synchronize, Read Attributes, Read' permission (0x100081) is not granted on file or directory (Access denied because the requested permissions are not granted by the access control entries) - Status: 1:60368617476:32:67 - - NT user name: DOMAIN\test2 - UNIX user name: pcuser(65534) - Qtree security style is NTFS and NT ACL is set on file/directory - Path: /vol/volCIFS/

wcc -s domain\test2 and fsecurity show /vol/volCIFS are OK (user is in the right group).

Did someone ever experienced that ? Any idea ?



We experience something similar. I am currently reporting this to our NetApp support.


I of course tried to deactivate SMB2 on each side (client / DC / filer), and it wasn't better.

But i found out that \\filer_ip\share was working, when \\filer_FQDN\share didn't...

NetApp support asked me to try to disable Resource SID Compression : (Microsoft KB 2774190).

I couldn't find the desired registry path and key on my system (no Kdc\Parameters key after HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System), but i created it.

Seems to work for the moment. I tried on ~20 clients. I'll keep you informated.


We experience the same issue. We migrated the CIFS shares from old Filer to new Filer. Both Filer have same settings except the Ontap version. Old Filer is Data Ontap 7, while new Filer is running Data Ontap 8. Appreciate if someone can tell us the solution for this issue.


Was there a solution ever provided by NetApp? Running into the same issue since deploying 2012 R2 DCs.


FYI - The reported issue above has been fixed in the latest releases of Data OnTAP. Information can be reviewed from the support site's bug reporting tool, ID # 648981. MS Article provides details for a work around as well.

I'm not sure what troubleshooting steps you have tried already, so forgive me if this is redundant. If the issue is still exists, I would focus in on these areas. What version of OnTAP are you running? Is the 2012 server the parent domain? What are your domain and forest level functionality levels? Can you provide your cifs options? Is this volume configured with multiple protocols? Are there any qtrees configured?

The Windows adminstrator within me wants to rule out DNS as a possbile cause. The fact that you are not able to connect via the fqdn raises a red flag once the kerberos is removed from the picture.When the issue presents itself, occurs, open up a command prompt and do a nslookup from each of your dns servers. Verify that it is returning the correct information for your filer. Run a dcdiag with your focus on the DNS for a through report on the Domain Controllers. The dcdiag will give you a comprehensive look at your DNS environment. I've seen pristine environments still come back with missing records.

Collecting a packet trace during the failed request will give us more information to proceed and help to further isolate the issue. This can be done from the storeage system or you can use wireshark.

Let me know if I can help further. Feel free to contact Netapp Technical Support or open a ticket via your AutoSupport site for additional help.


Good Morning Dave,

Thanks for the information. We are currently running ONTAP 7 mode and

have been told by our vendor that we need to upgrade to version 8.2 or 3 to

avoid another issue with the system. We are in the works of planning for

the upgrade. I did perform the registry hack as stated in Microsoft's kb

and haven't had any issues with Share access in 3 days now. But will

continue to monitor and will close our internal ticket on Monday if no more

issues are found.


Daniel J Skelton

*Please note my email address below has changed.

Service First Safety Always

VE Tech North America

Server Engineer

8450 W Forest Home

Greenfield, WI. 53228

Work: 414.367.5445

Cell: 414.687.8334

This e-mail message from VE Tech North America, for the sole use

of the intended recipient(s) and may contain confidential and privileged

information. Any unauthorized review, use, disclosure or distribution is

prohibited. If you are not the intended recipient, please communicate with

the sender by reply e-mail and destroy all copies of the original message

and delete same from all computers.

On Tue, Jan 14, 2014 at 12:20 PM, David Hesford <