Windows 7 failing to access network shares by netbios name / fqdn (Folder Redirection Failure with Error 502 Access Denied)
This problem is of the strangest kind. I've been designing and deploying Windows networks since Windows NT 3.51 and have never seen anything like it. What's worse, it's going to be very difficult to describe but I'll give it a shot... I have a server, a domain member, sitting out in site a. I'm attempting to set up folder redirection for some of the Win 7 folder structure with this server as the target. \\server\share$. The clients are in another physical site. The FQDN for the server follows this format server.sub.domain.com. I've created 3 test shares on the server, share1$ share2$ share3$. Permissions are set correctly on both the share and the shared folder (NTFS). I have 3 test workstations all running Win 7 Ent with SP1. They are all joined to the domain. All can log in and apply group policy, etc... No issues there. I have 6 test user accounts test1 through test6 User test1 logs into test workstation 1 and attempts to access the share using \\server\share1$ - the workstation never puts a packet on the network. it immediately responds with the following: " Network Error Windows can not access \\server\share1$ You do not have permissions to access \\server\share1$. Contact your network administrator to request access. " If I then attempt to access \\server.sub.domain.com\share1$ I gain access. If I then log into the second test workstation and attempt to access \\server\share1$ or \\server.sub.domain.com\share$ I get the same network error seen above with both references to the share. I've monitored network traffic with netmon, wireshark, and at the firewall between the two sites. Whenever the client responds with the network error, it generates no traffic between itself and the server with the share or between itself and the DNS server. It just decides internally somehow that without even attempting to contact the server that the logged in user doesn't have access rights to the share. If I then attempt to access \\(the server IP address)\share1$ I can get in every time. Now, I've mentioned that there are three shares on the server. This is why I mention it. If I attempt to access \\server\share1$ I get network error, access denied. If I attempt to access \\server\share2$ I get in. If I attempt to access \\server\share3$ I get access denied again. As I move between the different test workstations, I get different results. Sometimes I can get in with \\server\share1$. Log into a different workstation with the same account and I get in with \\server.sub.domain.com\share1$. Log into client 3 and neither \\server\share or \\server.sub.domain.com\share will grant me access for the test1 user. If I then log into the same three clients with the test2 user I will get similar results as far as accessing the share but different in that I can't access the same share/s that test1 could and/or I can't access them using the same reference to the share. In all cases I can sub the server's IP for it's name and get in. It is not a name resolution issue either. ping server returns the correct results even when \\server\share1$ will not grant me access. ping server.sub.domain.com returns the correct results as well on systems that won't grant me access to \\server.sub.domain.com. the server name is resolving. The client just isn't attempting to resolve it because ??? I don't know why. No traffic passes between the DNS server and the client or the server hosting the shares and the client when the access denied error occurs. To make things more interesting... If I log into the same client workstation with a different account, the ways I can access the share change. For example, on client 1 logged in as test1 user, I may not be able to access any of the shares using the \\server\share reference and I may be able to access 1 of 3 shares \\server.sub.domain.com\share. If I then log out and log into the same client as test2 user I can access 1 or 2 of the shares with \\server\share but not all three and none of them via \\server.sub.domain.com\share. test3 user on the same workstation will not be able to access any of the \\server\share instances and only 1 of the \\server.sub.domain.com\share instances. In all cases, on all machines, If I substitute the servers IP address for the netbios/fqdn name I can access all three shares. I've tinkered with the network binding order and network interface access order for the client systems network adapters. I've disabled IPv6 thinking it may be trying to access the share via that method which wouldn't get passed by our routers. I've enabled NetBIOS over TCP/IP on the WINS tab in the network settings as opposed to having it set to the default to take it's queue from DHCP and enable if DHCP doesn't specify. I've disabled IPv6 on the Server, thinking it might be registering the v6 address in DHCP and the client is picking this up. (This isn't happening however as when I get the access denied error no traffic passes over the network adapter, neither a name lookup or an attempt to access the server.) I'm at a loss. Any suggestions / ideas / off the wall hair brained schemes are welcome. Thanks, SteveDiG
March 31st, 2011 12:02pm

Hi, In order to narrow down the system operation issue, I suggest to perform these tests to troubleshoot the issue: 1 Login with Safe Mode with networking or Clean Boot 2 Temporally disable firewall on Windows 7 3 Register DNS via command on Windows 7: 1) ipconfig /flushdns 2) ipconfig /registerdns Furthermore, you can you use the Network Monitor to capture the network traffic, run the monitor when you try to access the share folder and end it when the accessing failed or succeeded. Comparing the different processes between the working client and problematic one to find which step cause the issue. Hope that helps. Regards, Leo Huang TechNet Subscriber Support in forum. If you have any feedback on our support, please contact tngfb@microsoft.comPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Free Windows Admin Tool Kit Click here and download it now
April 5th, 2011 5:13am

OK, I've run this down a bit further. It's tied to Folder Redirection. If I remove the GPO that sets folder redirection to the server and then log in with any of my test user accounts, the user can access all three shares and create folders on them via both naming conventions ... \\server-name\share$ and \\server-name.sub.domain.com\share$ If I enable the group policy that redirects folders I get the results indicated above. As I've said before, I did netmon and wireshark captures and when the system is being denied access it isn't sending a single packet over the network to the file server. I'm fairly certain that this is because it has a deny access token cached from it's attempt to redirect the folders. Access denied, why even try again... I've disabled fast logon via group policy, forcing the client to complete network auth before applying group policy but I still get intermittent access denials for various users. What I'm seeing more now is the first user to log onto a freshly imaged box will get the folder redirection correctly. If I then log out with user 1 and log in with user 2, user 2 is denied access to the folder redirection target. Not sure why this is. Both users are the same as far as rights and group membership, etc... I wonder if I'm not giving enough time for the file server to realize that the connection from the workstation has been closed down and is having conflicting credentials issues somehow, multiple users from the same IP but this shouldn't be an issue. If it were things like fast user switching would cause a heck of a lot of network resource access trouble. I'm sure that something isn't registering properly during the folder redirection attempt at logon and this is caching an access denied token locally that is stopping the client system from being able to access the share once the logon process is complete. The question now is why and how do I correct it. I'm open to suggestions / ideas (sane or crazy.) Thanks all. SteveDiG
April 5th, 2011 5:01pm

Hi, The issue should not related with folder redirection GPO, that may related with your Server Configuration or firewall settings. I suggest to temporally disable firewall on Server. Furthermore, please try to clear Kerberos Authentication Tickets cache for test: http://technet.microsoft.com/en-us/library/cc738673(WS.10).aspx You can view and purge the ticket cache by using the Kerberos Tray tool icon located in the notification area of the desktop. By positioning the cursor over the icon, you can view the time left until the initial ticket-granting ticket (TGT) expires. Hope it helps. Regards, Leo Huang TechNet Subscriber Support in forum. If you have any feedback on our support, please contact tngfb@microsoft.comPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Free Windows Admin Tool Kit Click here and download it now
April 6th, 2011 4:37am

This is most definitely tied to the folder redirection GPO. I have completely disabled the firewall on the server. This made no difference. It's back on now and things still work as they did before. Clients that don't have the folder redirection GPO applied can access the share/s with no problem. Clients that do have folder redirection applied are, with the following caveats, unable to access the share. Test Setup: 1 Win 2K8 R2 file server in a remote site. 3 freshly imaged win 7 workstations 6 user accounts all configured exactly the same as far as group membership, permissions, etc... Results: Test User 1 logs into workstation 1 after the clean deployment. The share is accessible and the folders are redirected. UserName folder is created on the share and the underlying folder structure is created. Test user 2 logs into workstation 2 after the clean deployment. The share is accessible and the folders are redirected. UserName folder is created on the share and the underlying folder structure is created. Test user 3 logs into workstation 3 after the clean deployment. The share is accessible and the folders are redirected. UserName folder is created on the share and the underlying folder structure is created. Now: Test user 1 logs out of workstation 1, test user 4 logs in. The share is inaccessible and no folders are redirected. (There is absolutely no difference between test user 1 and test user 4) Test user 4 logs out of workstation 1, test user 1 logs in. The share is accessible and redirection is functional; sync working for off-line access, etc. Reboot workstation 1 Log into workstation 1 with test user 4. The share is inaccessible and no folder redirection occurs. Test user 4 logs out of workstation 1, test user 1 logs in. The share is accessible and folder redirection occurs. reboot workstation 1 Test user 1 logs into workstation 1, the share is accessible and folder redirection / sync works. Further in this vein... Test user 2 logs out of workstation 2, on which the user successfully accessed the share, created their redirected folder structure & successfully synchronized their local cache. User 2 logs into workstation 1, where user 1 just successfully completed the same process, and gets access denied attempting to access the folder redirection share. No folder redirection takes place. So, that is three accounts tested on workstation 1. The first is the fist user of the workstation; all works well. The second is test user 4, a user account who doesn't have any folder redirection in place previously, the same as user 1 in all regards, yet user 4 gets access denied. If I go and look at the security event logs on the file server I can see test user 4 successfully authenticating to the file server. There are no access denied msgs, just the successful logon of type 3 (via the network) as you would expect. The third is test user 2 who has successfully logged into workstation 2 previously and created their redirected folder structure on the share ... i.e. they have all necessary permissions. This user gets access denied when logging into workstation 1 but successfully redirects folders and can access the share on workstation 2 where he was the first user to log in. What makes it even worse, I can look in the security event log on the file server the share is on and all users authenticate successfully to the server, whether they are successful in redirecting folders and accessing the share or not. Test user 1 thru 6 all have successful type 3 logon events registered on the file share server during all logon attempts. I get the same results rotating users on the other two test machines as well. The first user to log into the workstation gets their folders redirected and off-line access set up. Other users logging onto the workstation do not. Latest theory/conclusion: (someone please sing out if you have contrary information.) Folder redirection will not work for any user but the first one that logs into the workstation when accessing via the cache. Further, the share is inaccessible to anyone else that logs into the workstation as attempts to access the share are being redirected to the local cache which is already owned by a different user. The target for redirected folders is in a data center on the other side of the US. The avg ping time between the two facilities is ~ 65 ms. The threshold for working offline is 50 ms by default which I lowered to 30 ms because these are all laptop users and I actually want them to work from their local cache 99% of the time with BITS synchronizing content in the background. What I believe is happening is once the local cache is claimed by user 1, no other user can place content in it. Further, since the work off line threshold is set below the average ping for the server, this is where all users go by default. Thus... access denied because the local cache is already owned by the first individual to log into the workstation. I believe the local cache is only capable of supporting a single user's access. Multiple users trying to place content in the share (actually the cache) is not possible and is resulting in the access denied messages for other users logging into the workstation. Does this sound right? I ask because I haven't been able to find any definition for how the local cache works in multi user client system environments. It certainly seems to align with the pattern of behaviour I'm seeing. I've done more looking for information on the above item. It would appear that CSC should support this. I haven't found any documentation saying specifically that it supports multiple user systems utilizing folder redirection for the likes of my docs, etc... but I have read in a number of places discussions on the csc size growing substantially on multi user systems because of multiple users caches being held there in. Still, the server is authorizing access but the client is still reporting access denied. I can't help but think it's tied to CSC as I lack other suspects at this point.
April 6th, 2011 4:17pm

Here is an update in case anyone is following this thread. This problem is 100% definitely tied to the Client Side Caching function. I can set the registry setting that formats the CSC dB and resets the cache and log in with any user I like; one that has folders already on the redir share or a new user that has never redirected folders before. Both types of users registered Access Denied to the redirection share if they weren't the fist user to log into the workstation with redirection enabled prior to the CSC reset. After the reset, I can log in with either type of account, new redirection or existing folders out there, and redirection will work for that user from then on with that client system. Any other users that log in return to getting access denied including the user account that originally was the first to log into the workstation and initially had folder redirection and off line access working. These are all W7 SP1 workstations. I'm going to deploy a pre sp1 W7 client and see if it displays the same results. Rgds, SteveDiG
Free Windows Admin Tool Kit Click here and download it now
April 7th, 2011 4:31pm

Just in case anyone is following this, I'll continue to maintain it and will update with a solution if/when one is found. I deployed a couple of Win 7 Ent clients that did not have SP1 installed. I logged into them with each of the test user accounts I've been testing the SP1 workstations with. All test users were able to log into each non sp1 machine. In all cases access to the share worked along with folder redirection and off line file synchronization for every user that logged into each workstation. Doing the same with SP1 clients results in the first user to log into the machine accessing the share and folder redirection working with subsequent users logins being denied access. The first user can log in and access the share and redirect folders with no problem going forward. Just the second user to log in and following users failing. The only way a user who was not the first one to log into the workstation with folder redirection enabled can operate on the system and get access to the share and their redirected folders is if you format the Client Side Cache using the procedure defined here: http://support.microsoft.com/kb/942974 Doing so really hoses the first user to have logged in however. Subsequent users who are denied access create local folders and thus although their folder redirection fails they wind up with a functional desktop, start menu, etc... If you reset the CSC and log in another user, then go back and log in the first user, the first user no longer has access to the CSC but their folder redirection bits are still in place and pointing to the cache so the users desktop, start menu, etc... are all blank and things like my documents are completely inaccessible. Very ugly. The first user to log onto the workstation is somehow locking the client side cache which is in turn denying access to subsequent users. This is in turn producing the access denied errors that are being seen for subsequent users attempting to apply folder redirection group policies.
April 8th, 2011 12:08pm

An additional update for anyone following this... I've found another means to enable follow up user's folder redirection to work on a workstation that has been previously logged into by another user with redirected folders. Unfortunately I can find no way to automate the workaround so it is dependent on manual steps to get it to work. Worse, they are steps the end users must take themselves. Once a user logs in and successfully redirects their folders, they must go to one of the redirected folders, say My Documents, and toggle the off-line state of the folder. If the folder is off-line at the time the user need only toggle it to on-line prior to logging out of the workstation. If the folder is in the on-line state, the user must toggle it off-line and then back to on-line. Doing so seems to adjust the state of the CSC so that the log-off process will release it for the next user of the workstation. This could be a functional workaround if I could automate it, say with a log-off script that toggled the state of the folder off and then on line as the user logs out. Unfortunately I can find no scripting interface that will allow this. I've been through VBScript and PowerShell with no luck at all. I was able to find some VBScript WMI code which will let me query the state of a given folder as well as set folders / files as available off line or not, but nothing to adjust the on-line state of the folder. The object that gives access to this property is read only. CSCCMD.exe does not work with Windows 7, a missing ordinal in a dll. Thus the tool is off the table for this purpose as well. There are API's that will allow you to write your own tool but my programming skills are insufficient for the task. It seems I have only two hopes. 1; MS has an unpublished hotfix for the problem. 2; MS has an unpublished command line tool that I can use to create a log off script to do the above. Rgds, SteveDiG.
Free Windows Admin Tool Kit Click here and download it now
April 9th, 2011 12:16pm

Now that I've tracked this back to the CSC I did a little searching in the forum and it would seem I'm not the first to experience this issue. See : http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/a0052ce8-e588-4cce-afec-a08de8a1143b Rgds, SteveDiG
April 9th, 2011 10:47pm

Please make sure applicable hotfixes for client and server are installed: 2473205List of currently available hotfixes for the File Services technologies in Windows Server 2008 and in Windows Server 2008 Is the user owner of their redirected share, if not TEST post that change, does that make a difference? TEST after giving Everyone full permission under Sharing permissions (not security) does that make a difference? Also use procmon (process monitor) to track where we are hitting the access denied error. If that does not solve the issue this will need more indepth diagnosis. Sumesh P - Microsoft Online Community Support
Free Windows Admin Tool Kit Click here and download it now
May 4th, 2011 12:24pm

Please see here for the permissions required for Folder redirection: http://technet.microsoft.com/en-us/library/cc781907(WS.10).aspx NTFS permissions required for the root folder User account Folder Redirection defaults Minimum permissions needed Creator/owner Full Control, this folder, subfolders, and files Full Control, this folder, subfolders, and files Administrators No permissions No permissions Everyone No permissions No permissions Local System Full Control, this folder, subfolders, and files Full Control, this folder, subfolders, and files Security group of users who need to put data on the shared network server N/A List Folder/Read Data, Create Folders/Append Data - This folder only Share-level (SMB) permissions required for the root folder User Account Folder Redirection defaults Minimum permissions needed Everyone Full Control No permissions (Use security group) Security group of users who need to put data on the shared network server N/A Full Control NTFS permissions required for each user's redirected folder User account Folder Redirection defaults Minimum permissions needed UserName Full Control, owner of folder Full Control, owner of folder Local System Full Control Full Control Administrators No permissions No permissions Everyone No permissions No permissions Sumesh P - Microsoft Online Community Support
May 4th, 2011 12:31pm

Look at the thread here: http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/a0052ce8-e588-4cce-afec-a08de8a1143b Hotfix KB2610379 released today solves the problem discussed in that thread and probably the issue SteveDiG discusses here.
Free Windows Admin Tool Kit Click here and download it now
October 13th, 2011 5:05am

Hi If this issue is cleared by setting the scope offline and then online again, I would suspect something wrong in the database rather than the fix in http://support.microsoft.com/kb/2610379 If reinitializing the database solves the problem (http://support.microsoft.com/kb/230738) I would recommend this as a general step before finalizing the image you are deploying to make sure there are no leftovers from the buildprocess itself in the CSC (Offline Files) database. Regards Roland [MSFT]
October 17th, 2011 4:21am

I've spent a good few hours on this problem and then came across this thread, many thanks to Steve for continuing to push for a solution and for updating here! For me the problem was accessing a CIFS share on an EMC box, by FQDN or IP it worked fine, by shortname (netbios) I got access denied. For me the solution was this as suggested by Roland http://support.microsoft.com/kb/230738 Thanks again, was driving me insane!
Free Windows Admin Tool Kit Click here and download it now
December 21st, 2011 3:24am

Thanks - this worked for us.
August 3rd, 2012 10:17am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics