We help IT Professionals succeed at work.

Windows 2003 folder security when using folder redirection issue

macleandata asked
Medium Priority
Last Modified: 2011-04-14
Hi.. I am facing problems with Windows 2003 folder security, I ve implemented the folder redirection for the users, and thats working fine, whats NOT working is that if the administrator logged on to the server which houses the redirected folders which also has permission to each users folder, creates a folder/file within the users redirected folders the user has the permission denied when accessing this folder
I have setup the parent folders permissions as follows: -

created folder, shared this to everyone

unticked allow inheritable permissions from parent
removed the already inherited permissions
added - administrators - system - creator owner
gave all full control
clicked advanced - added .. authenticated users
allowed  create folders - append data - read permissions - read attributes & read extended attributes
And applied to - this folder only

Ive tried altering the applied to bit  to - this folder, subfolders and files ..but nothing

please help

Watch Question

This does make sense.

Effective rights on a file an Administrator creates will be as follows:

administrators : FC
system : FC
creator owner --> the Administrators group : FC

- added .. authenticated users
allowed  create folders - append data - read permissions - read attributes & read extended attributes
 ^^^ This line doesn't say "Authenticated users may read data", especially if security is not propagated to subfolders.

You probably need the "Read data" permission for authenticated users here.


Hi Rant32.... thanks for your swift response, i have applied this option, but what I have noticed, is that the folder created by the administrator is not inheriting the same permissions as any other folder within say "My documents" its not applying the authenticated users nor the users name, I have on the top folder where the original settings reside ticked the option in advanced  to - replace permission entries on all child objects shown here that apply to child objects... just as i was writing this its just occured to me that because the authenticated users is applied to folder only that ticking that option will not push down for for the subfolder ie.. username and so on, so I have changed this to "this folder, subfolders & files" .. which has worked, but now gives each user access to all other users folders.. aarrr

anymore suggestions... i know if i apply the username manually it will solve problem but i want it to be right from the start and to cut down on extra work for my colleuges, as we have to drop stuff onto peoples mydocs all the time

You will have to make sure that the user has change permissions on his own folder, and that has to apply to all subfolders and files. Do not use the Authenticated Users group on any user's folders.

If there are too many user home folders to do this manually, AND the user names are the same (or can be derived from) the folder names, then you can script that in a for-loop with cacls, as in (DON'T try this blindly on your data, I've added an echo too so you can see what happens):

D:\Fileserver\Data\Home> for /d %f in (*.*) do @echo cacls "%f" /G %f:C

See "CACLS /?" for help on the command-line version of the security tab.

The easiest way around this, is to have the user's home folder setup when creating the user account, i.e. connecting a drive to \\fileserver\home\%username% in the Account tab of the user profile. That way, security is set correctly automatically.

That 'dropping stuff' part, does that mean you MOVE a file from one place to another? In that case, if the file is moved between folders on the same share or drive, that means that permissions are kept on the original file. IE, if the file is in your home directory, and only you have permission, then after moving that file you will still be the only one having permissions. Try copying instead.


hhhmm bugger...okay, i will run this on the test system, the other option, we already have in place but no one uses it and continues to just use thier my documents which is part why we have choosen to go down the redirection root.... other reson is were moving all account onto a new server...

thanks alot for the information youve given.. i will apply to test system and let you know


I don't exactly know what you mean by moving accounts to a new server... They're not in a domain?

If you're re-creating user accounts, anyway, this is the time to set up Home directories properly. This works perfectly in conjunction with My Documents redirection, because you don't have to configure a path - just redirect My Documents to the Home drive in a GPO. Ideal for mobile users, too.

Then you'll never have to worry about folder redirection, security and scattered documents again ;-)


sorry for delay in getting back to you, yes we're on a domain I meant users profile folders not the accounts being moved to new server, the oringinal server originally housed everthing including AD and both user profile folders and their home folder which is connected to with a virtual drive .. not local path....okay that sounds like a good idea ..i did give some thought about redirecting in their home folders but it seemed at the time ..obviously until i came up with the permission problem ..easier to scrap it and just use a new location and do away with the connected home folder.

hhmm so how will that work as everybodies home folder is currently setup with the folder call ...e.g - SERVER d:\Userdata\fred-bloggs$ , and  the home folder on their account -  have connected this using drive letter & \\server\fred-bloggs, but when applying the redirection in group policy the users folder is not shared, so how do i get it to redirect to fred-bloggs as apposed to fredbloggs (%username%)
Uh, well... the idea is still to use the "Connect home drive to" on the Account tab of the user.

You'll make it a whole lot easier on yourself if the folder name is the same as the %username%.

The point is, connecting a drive to \\server\%username% doesn't work very well, because then %username% is the share name, and the server won't automatically create the folder and the share for you (it won't know where to create the folder). That's all manual work.

My default practice is to create a "Root home-folders" share on the fileserver. Just one. You can call the share \\Server\Home$ or whatever.

Only administrators have access to it - better yet, create a special security group that can manage user's home folders as required by your organization, so not every domain admin can have access to all user data (users love that). Users have List folder contents access on that folder *only*. Then the user's home folder (on the Account tab) becomes \\Server\Home$\%username% - Et voilá, when you click OK...

- The new user directory is automatically created
- Permissions and ownership are set correctly
- The Administrators/special group still has the access as granted on the Root home-folders
- The drive mapping is created as expected (not on Win95 or 98 because they can't map to a deep share, but who needs 9x)
- You can redirect My Documents to "The home drive" without setting the absolute path in the policy
- %homedrive% and %homepath% is set for you to use wherever you need it
- Need I go on?

Ehh... am I making sense? - Try it on a couple of test accounts... You'll love it ;-)

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts


great okay, yes this makes good sense, I will set this up and see how i get on ..thanks alot


Hi ...sorry for delay in getting back to you... this works a treat.. have now got this in place on live system with no trouble at all...thanks so much for your help on this
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.