You open a user’s redirected Documents folder on the file server and Windows tells you access is denied. You are a domain admin. You can see the folder in the list. You just cannot open it.
Nothing is broken. Windows is doing exactly what Group Policy told it to do, and the setting that told it is switched on by default.
Why folder redirection shuts admins out
When Group Policy creates a redirected folder for a user, it writes the permissions on that folder at the moment it is created. One checkbox decides who gets in.
On the Settings tab of a redirected folder’s properties in Group Policy, there is a setting called Grant the user exclusive rights. Microsoft’s documentation is blunt about it: this setting is enabled by default and is a recommended setting, and it “specifies that the administrator and other users don’t have permissions to access this folder”.
So the access denied message is the feature working. The user and the local SYSTEM account hold full control of that folder. Nobody else does, and that includes you.
That is fine right up until something legitimate needs to read the folder. A backup job that keeps reporting errors it cannot explain. A migration to a new server. A staff member who has left, and a manager who needs the quote they were working on.
Check what you are actually looking at first
Before you change anything, confirm the problem is the folder and not the share.
Open the properties of the redirected folder, go to the Security tab, then Advanced. Look at two things: who the owner is, and whether inheritance is disabled. On a folder created with exclusive rights turned on, the owner is the user, inheritance is off, and the only entries are the user and SYSTEM.
If the whole share is unreachable rather than one user’s folder, the problem is at the share root instead, and the fix is different. Check the share permissions and the root folder’s access control list before you go near individual user folders.
Fix 1: stop it happening to folders you have not created yet
In Group Policy Management, edit the GPO that does your redirection and go to User Configuration, then Policies, then Windows Settings, then Folder Redirection.
Right click the folder you redirect, for example Documents, and choose Properties. On the Settings tab, clear Grant the user exclusive rights, then apply.
That is the whole change. From then on, new redirected folders inherit their permissions from the share root instead of being locked to the user, so whatever you have granted at the root applies.
It does nothing at all to folders that already exist. Those permissions were written when the folder was created, and unticking a box later does not go back and rewrite them. That is the part most guides skip, and it is why people untick the box, wait a week, and find they still cannot get in.
Fix 2: repair the folders that already exist
There are two ways to do this and one of them will ruin your afternoon.
The tempting one is takeown /r. Read Microsoft’s takeown reference before you use it: the /d Y option that suppresses the prompt is documented as taking ownership of the directory and replacing the directory permissions “with permission granting the user full control only”. Run that across a share of redirected folders and you will strip every user’s access to their own files.
The safer route is icacls, which changes the owner and adds permissions without flattening what is already there.
Set the owner first, on one folder:
icacls "\\fileserver\users$\<username>" /setowner "<DOMAIN>\Domain Admins" /T /C
/T applies the change through the subfolders and files, and /C keeps going if it hits an error rather than stopping halfway.
Then add the access you need, inheritable, without removing anything:
icacls "\\fileserver\users$\<username>" /grant "<DOMAIN>\Domain Admins":(OI)(CI)F /T /C
The (OI)(CI) pair is what makes the permission flow down to files and subfolders. Note the difference between /grant and /grant:r in the documentation: /grant adds to the existing explicit permissions, while /grant:r replaces them. For this job you want /grant.
Check the result before you touch anything else:
icacls "\\fileserver\users$\<username>"
Run all of it against one folder belonging to someone who is sitting at their desk, and have them open a file, save it and create a new one. Then do the rest.
What the permissions should look like
Once you are back in, it is worth setting the share up the way Microsoft documents rather than leaving whatever has accumulated.
For a file server that is not also running Remote Desktop Services, Microsoft’s permission table for the redirected folders share is:
- SYSTEM: full control, applied to this folder, subfolders and files
- Administrators: full control, applied to this folder only
- Creator Owner: full control, applied to subfolders and files only
- The security group of users who put data on the share: list folder and read data, create folders and append data, read attributes, read extended attributes, read permissions, and traverse folder, all applied to this folder only
- Everything else removed
The older Microsoft article on security enhanced redirected folders sets it out the same way but gives Domain Admins full control through the whole tree, which is what you want if administrators need routine access rather than exception access. Pick one and be consistent, because mixing the two is how you end up back where you started.
That article also makes a point worth knowing. Since 2017, when a user creates their own folder under the share, Windows converts the Creator Owner entry to a permission that applies to that object only. Users still work fine day to day. It only shows up when an administrator needs to work on the contents.
The decision nobody writes down
Turning off exclusive rights means your administrators can read staff members’ redirected files. Documents, Desktop, whatever else you redirect.
That is a business decision, not a technical one, and it is worth saying out loud to whoever runs the place. Most owners are fine with it once they understand that backup and recovery need it. Very few are fine with finding out later.
Write down who has that access and why. If you are in an industry with privacy obligations, that note is the difference between a considered arrangement and an awkward conversation.
Keep it from coming back
- Clear Grant the user exclusive rights before you redirect anything new, not after.
- Grant permissions to security groups, never to individual accounts. Staff change, groups do not.
- Keep a short written record of the share path, the GPO name and the groups involved, somewhere that is not on that server.
- Test a restore of a redirected folder, not just the backup job’s green tick. A backup that cannot read the folder often still reports success.
One step for today: open one redirected folder’s Security tab and look at the owner. If it is the user and inheritance is off, every folder on that share is the same, and you now know what you are dealing with before the next backup failure or departure.
If you would like a second opinion on how your file server is set up, get in touch.