[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 339
  • Last Modified:

Unable to Modify Folder & Files in User Home Directory - Windows Server 2003

Hello Experts,

I have a user that can't modify any files or folders within his Home Folder on the Windows 2003 Server. The weird part is that he can create new files or folders but cannot rename a folder or save a document after editing it.

I've checked the shared permissions (set to Full Control) and NTFS permission (set to User Account - Full Control).

0
katredrum
Asked:
katredrum
  • 5
  • 3
1 Solution
 
PeteJThomasCommented:
Well, by the description of functions available (and ignoring everything else), it implies that the user does NOT have the delete permission to their home folder.

Renaming involves a delete operation, as does saving a document after editing. So as a starter, this is where you should concentrate.

Have you tried using the effective permissions tab in Advanced Security of the folder? Go to security tab > Advanced > Effective Permissions tab. Add the user account as the account to check, and see what results you get? This should evaluate all effective permissions, including ones inherited from parent folders etc.

I think you'll probably find that somewhere in the tree, the user has been denied the 'Delete' or 'Delete Child' permissions, which will have the exact effect you're seeing...

Can you take a look and let me know?

Pete
0
 
katredrumAuthor Commented:
Hey Pete,

I've checked the effective permissions and it shows all boxes check hence Full Control. Actually this user can delete folders and files, he just cannot modify (change name or save a word doc or excel spreadsheet).


0
 
PeteJThomasCommented:
Well I have to say that is pretty weird - Though it's not the first time I've seen the Effective Perms tab be 'mistaken' - It should evaluate everything, including group membership etc, and give you a definitive result, but sometimes there is still something missing or wrong somewhere that gives innacurate results.

My first instinct with a problem like this, would be to completely reassign the permissions from scratch, as all indications are that everything is right. So, remove the user from the ACL completely - both share and NTFS (and any groups they are a member of - Just ensure to keep yourself in there somehow) - take ownership of the folder (take a backup of the folder if you feel it necessary before doing this).

Now you have ownership and the user account has been removed everywhere, add the user explicitly to both share and NTFS permissions again - Give them FC if you wish, or just MODIFY (only different is that with FC they are also allowed to edit permissions, which is not necessary, so MODIFY would suffice).

Then try again, and see what happens. The key lay somewhere in the fact that it's Office files that give the problem, as these types of files do act differently to a lot of others, in that nearly all operations (other than opening) on an Office file require delete permissions, and bare in mind there are 2 forms of delete permissions - There is a simple 'Delete' (which can be applied to both folders and files) and a 'Delete subfolders and files' (which can be applied only to folders) - If they''re denied either, it will stop them from being able to do what you need them to do (though as you know, this should also stop them from deleting normal files).

Anyway, failing all of that, can you advise how the folder security is configured? I mean, is it inheriting perms, or is inheritance broken for this particular folder?

And what happens if you move the folder OUT of it's current tree location to somewhere 'more accessible' - Do you still get the same probem, or can you then do what you want with the files?

Please let me know your findings, and hopefully we'll figure this out!

HTH

Pete
0
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

 
katredrumAuthor Commented:
Pete,

I took your advice and created a new user from scratch and mapped their H: Home Folder to \\fileserver\home folder$\%username% without any problems.

I was expecting that this will work as intended but in my testing came across the same issue as the user that initially had the problem.

Now I believe there is something wrong on my file server. My Home Folder structure is:

D:\Home Folders\Username
Home Folders does not inherit from D: and has three entries that is configured FULL CONTROL (Administrators, CREATOR OWNER, SYSTEM).

The \\fileserver\home folders$\ shared permissions is (Everyone - Full Control) and NTFS permissions is (Administrators, CREATOR OWNER, SYSTEM - Full Control).
0
 
katredrumAuthor Commented:
I have confirmed that I am able to modify files and folders in all other shares on the D: drive.

I have also confirmed that I can modify any files in the Home Folders share with my administrator account.
0
 
PeteJThomasCommented:
Ok, how exactly are you 'mapping' these home folders? Using the 'Profile' tab within the properites of the user object in AD?
0
 
katredrumAuthor Commented:
Pete, you lead me in the right direction. I have logon script that renames the Home Folders and it seemed that the script had something the user account didn't like. I do still use the profile to specify what drive letter and location.

Thanks for your help! A+
0
 
katredrumAuthor Commented:
Thanks again!
0

Featured Post

Visualize your virtual and backup environments

Create well-organized and polished visualizations of your virtual and backup environments when planning VMware vSphere, Microsoft Hyper-V or Veeam deployments. It helps you to gain better visibility and valuable business insights.

  • 5
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now