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.
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).
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.