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