I've got one Domain Controller for our small network (~20 users). It's running Win Server 2k3.

I have added a Global Security Group (MYDOMAIN\GroupA) and added 3 users to it (MYDOMAIN\UserA, MYDOMAIN\UserB, MYDOMAIN\UserC).

I have a separate computer running Windows Server 2k3 that's named fileserver (you guessed it, it just has file shares on it). It's joined to the domain.

I have a share:


I have set it up to be shared with Share Permissions: "Everyone / Full Control"

Then the NTFS permissions only permit MYDOMAIN\GroupA to have Full Control over it.

However, I'm experiencing very strange problems.

I have 3 workstations (2 XP and one Vista) that are joined to the domain and UserA, UserB, and UserC are all logged in to MYDOMAIN.

UserA who is running XP can run \\fileserver\ShareOne and access the files fine.

UserB (on XP) and UserC (on Vista) however type in \\fileserver\ShareOne into Explorer, hit enter and are greeted with a friendly "Access Denied" error.

I even had UserB (whos on XP) restart their entire machine, relogin and they still cannot access the share.

Why would this be happening? Something very very strange is happening.

  • Have you checked Event Viewer yet, anything relevant?
    – AdminAlive
    Dec 9, 2009 at 23:39
  • No relevant Event Viewer entries.
    – smoak
    Dec 9, 2009 at 23:48

5 Answers 5


I'd strongly recommend turning on auditing of "Logon" failures in the local security policy of FILESERVER (Start / Run / GPEDIT.MSC - Navigate to "Computer Configuration", "Windows Settings", "Security Settings", "Local Policies", "and "Audit Policy"), run "GPUPDATE", and watch the "Security" event log after a failure to see what shows up. (I am assuming, by way of directing you to the local security policy, that you don't have domain policy overriding it.)

Can you verify that other combinations of client computers and users do or do not exhibit the problem (i.e. "UserA" on the comptuer normally used by "UserB", etc)?

This has the feel of a problem re: SMB signing or NTLM level, but I'd think that all your OS's are set to their stock confgurations and should work fine. Just for kicks, run Resultant Set of Policy on a working and non-working client computer and compare the settings in "Computer Settings", "Windows Settings", "Security Settings", "Security Options" related to "Domain Member: ..." and "Microsoft network client: ...".)

One more silly thing: Is the name FILESERVER resolving to the same IP address on all the clients?

  • That pointed me in the right direction. The issue still persists. However, I just found out there are users on the local machine with the same name as the domain user (e.g. FILESERVER\UserB is located on the fileserver). When UserB went to access the share, I saw a Success log on for FILESERVER\UserB but they still got an Access Denied which I suspect is because FILESERVER\UserB is not in the ACL.
    – smoak
    Dec 11, 2009 at 2:05
  • Nuke or, failing that, rename the local user account. I wonder if UserB has a saved credential for FILESERVER referring to the old local account. Hmm... Dec 11, 2009 at 2:12
  • Thank you! That should hopefully help to squash this problem. I'll let you know how it goes. I suspect what's happening is that they connected to the Fileserver with a specific user name and password and hit Remember password and so it's using that cached info to access the file share.
    – smoak
    Dec 14, 2009 at 19:10
  • Yes, it's definitely using the user on the fileserver to authenticate with. I looked at the Security even logs and say a success logon for FILESERVER\UserB...the only problem is that UserB's computer doesn't have any saved passwords like the article above mentions. I am going to try renaming the FILESERVER\UserB user and have the user log off and on again and see if that fixes things.
    – smoak
    Dec 14, 2009 at 19:27

Have you tried the two user accounts that are denied on the computer than has the user working fine? This may at least work as a process of elimination. If they can access it okay through that computer then perhaps suspect the computer configuration or domain/computer relationship. Perhaps disjoin them and rejoin them to the domain. But first check if the user accounts can access the shares on that other computer. Or you could create another share with everyone with access to it and see if these user accounts can access this on at all. This may give you a little bit more insight into the matter as well.

  • Will be trying that as soon as I can (don't want to disrupt workflow too much)
    – smoak
    Dec 9, 2009 at 23:49

Silly question but are UserB and UserC in a group that has a "deny" entry in the ACL? You might want to check the Advanced permissions here too, as sometimes entries there don't show in the standard list.

If that's not it, generally what I do in these scenarios is try to narrow it down to a user or a machine problem, so I would get UserB to log on to UserA's machine (and vice-versa) and see what happens. Same with UserA and UserC. Based on the info from that exercise you should know whether to go looking at the user accounts or something on or with the PCs for further troubleshooting.

If you determine that it's the users, the next logical step would be to create test user accounts by copying the live ones, then trying to reproduce the problem yourself.

  • There aren't any deny entries. Only the one Allow entry. I'll try having the users log on to each others machines.
    – smoak
    Dec 9, 2009 at 23:42

Here's a long shot. Can your client machines browse to the server on the network and actually see the share? I have seen similar behaviour in the past that was related to browsing issues. Permissions were find but the machines couldn't locate the server and Windows error messages are known to be somewhat misleading at times.

  • Yeah all 3 users can browse to the fileserver via My Network Places, once there it lists the share but when they try to open it that's when the Access Denied happens (except for UserA).
    – smoak
    Dec 10, 2009 at 17:58

Check the permissions on the volume (drive) where the share is. Each user needs to have the "Bypass Traverse Checking" user right in order to get to the shared folder and it's contents, regardless of the permissions on the share itself. Make sure that the users have the "Traverse Folder\Execute File permission at the volume (drive) level.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .