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.
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.
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 10.2.201.112
[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 10.2.201.112 accepted.
sectrace from client 10.2.201.112 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 - 10.2.201.112 - 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 ?
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 : https://kb.netapp.com/support/index?page=content&id=2017211 (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.
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. http://support.microsoft.com/kb/2774190.
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
8450 W Forest Home
Greenfield, WI. 53228
This e-mail message from VE Tech North America, Inc.is 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 <