I've run into a rather interesting issue when playing with one of my domain labs.

There's a directory on a 2008 R2 fileserver that's being used for folder redirection for all users in the "Staff" OU. The directory has the following permissions set:

  • FILESERVER\Administrators: Allow full control to the directory, subdirectories, and files
  • DOMAIN\Domain Admins: Allow full control to the directory, subdirectories, and files
  • Authenticated Users: Allow create files, create folders, write attributes, and write extended attributes to the top directory only

In addition, the directory is also a network share with "Allow full control" to the Authenticated Users group.

When user john.doe, a member of the domain admins group, tries to access the directory from the fileserver, he gets the error "You don't currently have permission to access this folder". Trying to access the network share from the same server also results in a permission denied error (although the user can still access his own directory within the share).

Accessing the share from another computer logged on as the same user allows access as configured.

The only way you can access the files in the directory while logged on to the file server is by opening an elevated command prompt. UAC is disabled for all computers in the domain through Group Policy (Run all administrators in Admin Approval mode enabled, and default behavior set to elevate without prompting).

All roads point to the user being allowed access, but it's still being denied. Any ideas?

  • Are there any Deny ACEs in the ACL? May 3, 2012 at 22:12
  • There are no deny permissions set in the ACL for the directory for any group or user. May 3, 2012 at 22:13

4 Answers 4


This is by design. UAC strips the admin credential from any un-elevated process. If you're attempting to use an un-elevated process to access a remote share using only admin credentials, UAC will strip the admin credentials from the process' security token and the process will receive an "access denied" error.

To remedy this you can:

  1. Don't use admin credentials to secure the folder (create a generic group just for this purpose), or

  2. Disable UAC on the fileserver (not recommended), or

  3. Enable the following registry key on the fileserver to disable just this portion of UAC.

More info: Description of User Account Control and remote restrictions in Windows Vista

  • So I just noticed this is from last May. Not sure why it appeared in my RSS feed this morning...
    – John Homer
    Feb 10, 2014 at 12:59
  • John, I'm happy to alter my answer and upvote you, but I wanted to be sure. The KB article reads "weird", under the Domain user accounts section, as if it wouldn't have any bearing at all. The OP stated he was on the file server accessing the local drives and the UNC path straight from the server. I don't have a quick way (but could if necessary) test the regkey but just asking if you are certain that this will indeed fix the issue exactly as the OP described and not just for remote UNC path access?
    – TheCleaner
    Feb 10, 2014 at 14:00
  • I've run into this issue numerous times. Accessing a share locally is the same process as a remote share. It still uses the UNC redirector to access the folder and would be subject to the same behavior. I'm guessing the remote machine was an older (non-UAC) version of Windows. Unfortunately, OP didn't provide that info. Just based on the info he did provide (especially the need to elevate for it to work correctly) leads me to believe that this is the issue.
    – John Homer
    Feb 10, 2014 at 18:48
  • Yes, understood, but he stated he first tried the local drive (no share) and then the UNC share. But I digress...I'll alter my post and upvote yours...I have no reason to not trust your answer.
    – TheCleaner
    Feb 10, 2014 at 18:57
  • Registry key did NOT work for me, even after reboot. Turning off UAC also did not work. Only the generic group worked for me.
    – skinneejoe
    Nov 25, 2016 at 18:45

UAC is stripping off the Domain Admin credentials on the server itself, it's part of how UAC (stupidly IMO) works. One option is to disable UAC on the server completely to not receive the "You don't currently have permission to access this folder" prompt.

EDIT: here's an example thread btw: http://social.technet.microsoft.com/Forums/en-US/winservergen/thread/9061bc1c-42ea-47ed-8c7d-56b07139fb86/

EDIT2: John's answer below might be exactly what you are looking for though. Try it out and report back if you can.

  • 5
    Another option would be to add an ACL to the folder for another group that the user is a member of, with the appropriate permissions.
    – Greg Askew
    May 4, 2012 at 2:04
  • Sorry TheCleaner, but you are incorrect. You don't have to disable UAC to make this work. There is a registry key (LocalAccountTokenFilterPolicy) which disables only this part of UAC. More info here: support.microsoft.com/kb/951016
    – John Homer
    Feb 10, 2014 at 12:41
  • @JohnHomer - see my comment in your answer. I'll alter my answer as a possibility but point out and upvote yours as well, if you are certain that KB article applies to the local server drive issues as well that the OP described.
    – TheCleaner
    Feb 10, 2014 at 14:01

If you enable launching Windows Explorer windows as a different user, then you can run one as administrator/elevated, and in that window you won't have this issue. The problem is that this is disabled so you can't have an elevated explorer window, and so you can't have admin rights in an explorer window (with UAC enabled).

Go to the key:


and rename the value 'RunAs' to anything else (eg: 'RunAsOld'). (This will require taking ownership of the key and giving yourself full access to it. Don't forget to run RegEdit.exe as administrator to get an elevated RegEdit.)

You should then immediately be able to use 'Run As Administrator' with Windows Explorer and in the resulting window you won't have the access issue. Without the registry change, even if you use 'Run As Administrator', you don't actually get an elevated window.


The best way is to change the registry key at

registry::HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\policies\system; key = EnableLUA
  • Make sure it is set to Value 0 to disable
  • You need to reboot to make it take effect.
  • Interface might show it as disabled while registry is enabled

You must log in to answer this question.

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