• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 324
  • Last Modified:

Can't give a single user full rights to a directory under a share

This uses Windows Server 2003.  The user is connected to the share.  There is a single directory located in that share that I want that user to have full rights to, but adding the users name under the security tab for that directory and giving the user full rights there isn't working.  What have I missed here?
.  
0
james_axton
Asked:
james_axton
  • 7
  • 6
  • 4
  • +1
2 Solutions
 
bank_on_itCommented:
There could be inheritable permissions for the folder from the parent folder. Also, are you the owner or do you have full rights to the directory yourself so that you can give rights to it?
0
 
james_axtonAuthor Commented:
Further up the directory chain there are rights that restrict Domain Users from doing anything other than reading.  I can't change this for just one user further down the directory structure?
0
 
sharkbot221984Commented:
Have you granted user access for the Permission's from under the Sharing tab?
0
Veeam and MySQL: How to Perform Backup & Recovery

MySQL and the MariaDB variant are among the most used databases in Linux environments, and many critical applications support their data on them. Watch this recorded webinar to find out how Veeam Backup & Replication allows you to get consistent backups of MySQL databases.

 
bank_on_itCommented:
All folders under the directory will automatically inherit the permissions of the parent folder. To change rights for that one folder disable the inheritable permissions, most likely it's enabled. In the properties of the folder go to security and then click on advanced. Check to see if the "Allow inheritable permissions from the parent to propagate to this opbect and all child objects" is checked and if so uncheck. This will take off any permissions set by the parent folder. Then you can add the user's access to that one folder and domain users to the read only access.Have user test to make sure they have the rights they need.
0
 
james_axtonAuthor Commented:
No.  Here's the structure:

\\CompanyShare\OneDir\File.txt

CompanyShare has many files and users that I want to leave alone, but OneDir is a directory that I want to give just one user full access to so that he can change File.txt.  OneDir is not shared; instead it is accessed through CompanyShare.
0
 
bank_on_itCommented:
It would still inherit permissions that are set for company share, which I'm assuming is set to read only for all domain users.
0
 
bank_on_itCommented:
You would take off the inheritable permissions for just onedir.
0
 
james_axtonAuthor Commented:
bank_on_it, is that what I missed?  How do I remove them for just that one directory?
0
 
bank_on_itCommented:
Right click on onedir and go to the security settings for it and go to advanced. There you will find the check box for inheritable permissions. If it's checked it takes the settings from it's parent folder. If it's not then you can make security settings for just it. When you uncheck the box you will get a pop up. It's basically saying you're removing all previous set permissions for the folder defined by the parent folder. The it will ask if you want to copy the settings or remove them entirely so you can set your own. You will probably want to remove and set your own. Then hit add and chose the user you want to specify settings for. Then make sure and add domain user settings back as well since it removed them as well. And make sure you don't take your own rights off or you will not be able to change the rights again.
0
 
PeteJThomasCommented:
Be careful here - If you're accessing this folder VIA the share, you need some sort of permissions to the share itself (at least Read at the share level, and at least 'Traverse folder' at the NTFS level).

Be sure the account is not Explicitly DENIED access anywhere (leaving it 'unspecified' is not the same as an explicit DENY).

Then you must break inheritance as suggested above by bank_on_it, and that will allow you to amend the permissions for this folder separately to it's parent folder.

Just remember that this means any changes you make at the share level, will NOT inherit down to the folder in question in the future. So giving someone full control to the share, will not transfer ANY rights to the folder below it once inheritance is broken.

This is a common practise, but can get messy, so you just have to watch your security changes a little more carefully when inheritance is broken.

HTH, any questions, just ask. :)

Pete
0
 
bank_on_itCommented:
Did you get your question answered?
0
 
james_axtonAuthor Commented:
bank, pete, I haven't solved the issue yet and it's getting very frustrating.

In the example above - \\CompanyShare\OneDir\File.txt - CompanyShare is a shared folder and it's mapped.  "Everyone" already has Read rights to this share but I added the user under "Share Permissions" anyway and gave him Read rights.  I then broke the inheritance and changed rights, even going so far as to check the file itself that I want to change.  It says this user has full rights that are NOT inherited, and yet when I sit down at that user's workstation and try to do anything, change the file, rename it, etc, it says Access Denied.  Does anyone have any ideas?

The user does not appear to be denied rights anywhere.
0
 
PeteJThomasCommented:
Ok, so in your example, you're opening the security props of "OneDir", and breaking inheritance in the advanced security props of that folder?

Then, ensuring the individual user is added to the NTFS security as having FC.

As this folder is NOT shared, share permissions have no affect to access within the folder itself, provided you can traverse the 'parent' share and any folders in between.

So, firstly, can you actually see the contents of "OneDir" as this user? Is it only when you try and make a change to anything that it gives Access Denied? So at the moment, it appears that the user is just getting 'Read Only'?

Secondly, you may as well give the user FC in the share perms of the root share - It's irrelevant anyway as you can just use NTFS perms to lock it down.

Thirdly, what does the 'Effective Permissions' tab tell you? In the Advanced Security properties of "OneDir", in the 'Effective Permissions' tab, select the user account in question - What appears below? FC as you expect? Or something else?

Lastly, try creating a new folder under "Company Share" - Just called "test" or whatever. Break permissions on it straight away, and remove everything there except your admin group. Then explicitly add the user and give them FC in NTFS.

Now try going to this new folder as the user - Same problem? Or does it allow the user to create/modify etc in this one?

Pete
0
 
james_axtonAuthor Commented:
Pete, thanks for the reply.  As I was following your checks I discovered the issue.  The user only had "Read" rights to CompanyShare.  Once I added "Change" to the user's rights the issue was corrected.  

The user was listed in Properties > Security of OneDir as having Full Control.  The user was not, however, listed explicitly under the Security tab of CompanyShare but did have "Read" rights under Properties > Sharing > Share Permissions.  Once I gave the user "Change" permissions under Properties > Sharing > Share Permissions the user was immediately (without rebooting) able to change files.

Is this really the proper was to accomplish giving a user special rights different from the rest of the network or did I mess something up along the way and just happened to get it to work by granting "Change" rights?
0
 
PeteJThomasCommented:
Ok, that's good, glad you sorted it!

So for the sake of explanation, let's create a new simple scenario instead of using yours (which is probably already tangled in both our heads!) First, quick clarification of terminology - When I say Share Permissions, I always mean " Properties > Sharing > Share Permissions", and when I say NTFS permissions, I always mean the Security tab.

So, you currently have \\Server1\RootShare. The Share Permissions are set to 'Everyone' Full Control (this is completely normal, as it doesn't confer more rights than necessary, due to NTFS permissions being more restrictive).

So that's that part nice and clear. Then normally, in NTFS permissions of the "RootShare", nearly everyone would have to have at least 'Read' permissions, as this allows them to traverse the folder itself, just to reach subfolders within (this can be set even more granularly,but may complicate this more than necessary).

Now, were that the case, due to permissions inheritance, every subfolder within the RootShare would also only allow Read permissions to all users. So, if you have \\Server1\RootShare\FolderA, the same users would have the same (Read Only) permissions to FolderA because that's what set in NTFS permissions in RootShare.

To have ANY subfolder with different permissions to it's parent (regardless of whether it's to allow a single user more access, or 500 hundred users varying levels of access), you have to break inheritance from the parent for that subfolder.

So if you wanted to grant "UserA" Modify access to FolderA, you have 2 options - Either give UserA Modify permissions (NTFS) to the RootShare (obviously not ideal as this then applies to every folder within RootShare as well), or break inheritance on FolderA first, thus allowing you to explicitly add UserA to FolderA's ACL, and allow him Modify, without affecting any other folders at all.

Does all that make sense?

If you follow that sort of theme (so whenever you create a new share, set Everyone Full Control in the Share Permissions straight away, then just NTFS to define who does what) you can't go wrong.

Just remember to keep note whenever you break inheritance on a folder, as when you've done this a 100 times it becomes very difficult to troubleshoot permissions problems! Things should be kept as 'inherited' as possible, breaking only when absolutely necessary.

I hope that goes some way to clearing it all up for you? (Probably made it worse??)

:)

Pete
0
 
james_axtonAuthor Commented:
Fantastic explanation Pete!  I'm going to double the points and then split them between you and bank_on_it.  I learned a great deal from this question!
0
 
james_axtonAuthor Commented:
Pete and Bank, thanks again!  Contributors like you two make Experts Exchange worth it!
0
 
PeteJThomasCommented:
You're welcome! I'm glad we were able to clear it up and get you moving again!

Thanks for the points, take care!

Pete
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

  • 7
  • 6
  • 4
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now