File sharing permissions

8035 pts.
Tags:
SBS
SBS 2003
Our Network Admin/Server Guru has left us rather stuck, attempting to take over some duties we are not properly trained in (Help!?!) After reading about file permissions in the SBS 2003 R@ Administrator's Companion, we attempted to lock down some folders at the client's request. We removed Everyone - Full Access from the Security list, and added in the specific groups who needed access. After some issues and subsequent consultation with others in the field, we added Creator Owner and System in along with Administrator and the access groups - all set with Full Access. Now we keep getting instances of some files within the affected folders "dropping" the owner, so each file may need to be accessed, taken ownership of, then security groups added individually. This may only affect some files within folders, or all of them. We're not sure what we missed when setting the intial permissions, but would appreciate any input on this - for future reference, as well as to help clear all current issues. Trial by fire......ouch!

Answer Wiki

Thanks. We'll let you know when a new response is added.

Instead of looking through every folder and trying to find ones that do not have the correct permissions. Go to the security tab and click on Advanced. Then make sure the bottom two check boxes are check then click OK. Inherit from parent will make this folder inherit all of the permissions from the parent folder. Replace permission entries on all child objects will do the same for all child folders.

Discuss This Question: 4  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • mshen
    Are these shared folders of system folders? If they are just file shares on the server, you do not need creator owner and system.
    27,385 pointsBadges:
    report
  • AndreaF
    I really don't mind that I may have added these groups in needlessly - my concern is what is causing the inconsistencies in security settings. I went in today to try and clear up an issue - 4 layers of folders all had the proper settings - but the 5th layer had discrepancies. I went through the entire contents of this at the second levl and down (now THAT time I do begrudge a bit) and found almost %100 was correct. Why the few oddball settings, is what has me wondering what we missed when making the initial security lock downs? The settings we do have to work on begin with taking ownership as Admin, so we can set the permissions properly. When we run across these (files or folders) they are "unable to display the current owner", and nopbody has access. Any thoughts appreciated, thanks.
    8,035 pointsBadges:
    report
  • Dwiebesick
    There could be a number of reasons for what you are experiencing. I will give you an example of what happens to ACL Inheritance propagation danger of file and folder movement See the bug-like feature in action A hands-on experience is worth a thousand words sometimes, and in this case the adage is absolutely true. The easiest way for you to understand the problem is to experience it yourself. Follow these steps to replicate the scenario on an NTFS volume on a Windows Server 2003 or Windows XP system: 1. Create a parent folder—for example, C:Data. 2. Create a subfolder—for example, C:DataTeamA. 3. Apply permissions to that folder so that TeamA has Modify permission. 4. Create another subfolder—for example, C:DataTeamB. 5. Apply permissions to this second folder so that TeamB has Modify permission. 6. Add a file to the TeamA folder—for example, C:DataTeamATeamAInfo.txt. 7. Add a permission to the file giving a user or group Full Control of that specific file. 8. Drag the file into C:DataTeamB. What do you expect the permission on the file to be after you’ve moved it? Common sense suggests that the explicit permission you added in step 7 would remain attached to the file, but that the file would now inherit its permissions from the new parent folder, TeamB. So TeamB would have inherited Modify permission, and TeamA would no longer have access. Not so! Open the Security tab of the file’s property dialog box and click Advanced. In the Advanced Security Settings dialog box, you’ll notice that TeamA still has access and TeamB does not. Even more interesting, the Permission Entries list cannot display where the permission is being inherited from. Now let’s make it even more interesting. Open the Security tab of the Properties dialog box of the TeamB folder. Clear the check box that allows TeamB Modify permission, click Apply, reselect the Allow Modify permission, and click Apply again. All you have done is removed and then reapplied the Modify permission for TeamB. Open the Advanced Security Settings dialog box for the file. Notice, now, that TeamB does have inherited Modify permission, and TeamA no longer has permission. The practical implication of this experiment is that, if you move files between two differently-permissioned folders in the same namespace (in this case, the C: volume) using Windows Explorer, the file will have an unexpected permission set until something happens to fix it! In short, whether it’s a bug or a feature, it’s both unexpected and inconsistent. The same thing happens in a variety of scenarios, including moving files between two sub-folders of a remote share, or using tools other than Windows Explorer. Scary, huh? What in the world is going on? This odd and potentially disturbing phenomenon is a result of the way ACLs are applied to NTFS resources. An object, such as our file, has a flag that enables the object to inherit permissions from its parent container that are themselves inheritable. The ACL on the file has specific, individual ACEs for each permission that applies to the file, including the inherited permissions. But what actually applies those inherited permissions? Well, there’s a process that I’ll call the ACL propagator that, when triggered, goes from a folder to its subfolders and files and applies the inheritable ACEs into the ACLs of the child objects. When you created the file in the TeamA folder, the instantiation (or creation) of the new object triggered the ACL propagator to apply inheritable permissions from the parent to the file. So the file’s ACL contained ACEs allowing TeamA Modify permission. You then applied an explicit ACE to the file. When you move a file in a namespace, you are basically renaming it, not moving it physically. So when you moved the file into the new folder, nothing triggered the ACL propagator to apply inheritable permissions (from the new parent folder) to the file. So its ACL kept its previously applied ACEs. Then you made a change to the second parent folder. Changing permissions on a container triggers the ACL propagator, so the ACLs of child objects were opened and modified correctly. Important Until the ACL propagator is triggered, permissions will be incorrect on the moved object. Windows Server 2008 corrects the problem by triggering an ACL propagation when a file or folder is added to a folder. Solving the problem There are several ways to solve this problem. One is to ensure that, whenever a file is moved into a new folder with different permissions in the same namespace, the ACL propagator is triggered. Use the following steps to do this: 1. Move the object. 2. Open the Advanced Security Settings dialog box for the object. 3. Clear the Include Inheritable Permissions check box (Windows Server 2008 or Windows Vista) or the Inherit From Parent check box (Windows Server 2003 or Windows XP), and click Apply. If you are using a Windows Vista or Windows Server 2008 system with User Account Control enabled, you need to click the Edit button before you are able to clear the check box. 4. When you are prompted to Copy or Remove inherited permissions, choose Remove. 5. Re-select the same check box, and click Apply. This triggers the ACL propagator to apply inheritable permissions from the parent folder to the object. That’s a lot of steps, isn’t it? Another option is to copy rather than move the object. When you copy an object, you create a new instance of the object, which immediately triggers the ACL propagator. You then simply delete the original item. The only potential pitfall with this method is that you might have explicit permissions assigned to the original object that you will need to maintain when you move the object. Therefore, rather than use copy and paste, use a command that can copy the object including its security descriptor. You can use xcopy.exe with the /x switch to copy a file with its security descriptor intact. On Windows Server 2008, you can also use robocopy.exe with the /copyall switch. By copying the entire security descriptor, you also maintain auditing and ownership information. Then delete the original file. Any utility that can copy or back up and restore an NTFS object while maintaining its security descriptor will similarly solve this unusual feature of NTFS permissions. Change the culture, change the configuration It is important to inform appropriate users and support personnel about the dangers of moving files between two folders with different permissions in the same namespace. Education can go a long way toward avoiding the inherited permissions trap. You can also enforce success by aiming for a configuration in which each folder with unique permissions is, in fact, its own share. A connection to a share creates a unique namespace. So if you move a file between two folders in two different shares, you are in fact copying the file—so the inherited permissions problem will not rear its ugly head. Unfortunately, in these situations you might run into another challenge: By copying the file, you are not keeping the security descriptor (ownership, auditing, and explicit ACEs) unless you again use a security-descriptor-friendly tool such as xcopy /x or robocopy /copyall. But aiming for a unique share for each folder with unique permissions is a decent idea. You might ask, “But won’t that make my resource namespace very flat and wide?” To which I will reply, “Yes, except that users won’t be going directly to shares—they’ll view your resource namespace with DFS Namespaces, which create a virtual hierarchy within which you can organize your shares in any structure that aligns with your business.” You begin to see why even a question as seemingly simple as, “How should I organize the folders on my servers?” can only be answered by a consultant with the truism, “It depends.” There are a lot of moving parts in Windows that must be aligned to your business requirements. Solution summary NTFS permissions that are inherited from a parent folder will stick to a file (or folder) when you move it to another folder. The permissions of the new parent folder won’t apply to the object until something triggers the ACL propagator. Therefore, it’s critical for security that you do not just move files between folders with different permissions. You must either move the object and then remove and re-enable inheritance to the object; or you must use a security-descriptor-friendly tool—such as xcopy /x or robocopy /copyall—to copy the object to its new location and then delete the original. Although Windows Server 2008 has addressed the problem by triggering propagation immediately when a file is added to a folder, it is nevertheless important to follow best practices to ensure that security descriptors are moved correctly. Additionally, if you change the NTFS permissions on a folder, which appears that you have done, then you should look at the advanced security settings tab. There you will see many options e.g. Apply To settings where you have to make judgement decisions regarding things like "This folder only', "This folder, subfolders and files", "Subfolders and files only" - You get the picture. AND then you can select options like "Inherit from parent the permission entries that apply to child objects. Inculde these entries explicity defined here" or 'Replace permissions entries on all child objects with entries shown here that apply to child objects", or both or none of these options. Here is an example of how to setup a home folder with proper share and permission settings 1. Share the folder a. Permissions are set to everyone (or Domain Users) full control 2. Administrators, System and Creator Owner a. Apply onto i. This folder, subfolders and files b. Permissions i. Full control 3. Authenticated users a. Apply onto i. This folder, subfolders and files b. Permissions i. Read Attributes ii. Read Extended Attributes iii. Create Folders / Append Data iv. Read Permissions 4. Add another Authenticated Users a. Apply onto i. This folder only (ensure you are working with top folder) b. Permissions i. List Folder / Read Data On Windows Server 2003 with SP1 or later, you can enable access based enumeration (ABE) http://tinyurl.com/cnn6w Windows Server 2003 Access-based Enumeration makes visible only those files or folders that the user has the rights to access. When Access-based Enumeration is enabled, Windows will not display files or folders that the user does not have the rights to access http://support.microsoft.com/kb/288991 let us know if you have additional questions
    2,235 pointsBadges:
    report
  • AndreaF
    I think this may have pointed me in the direction I needed to go, thanks. I don't know that staff have been moving any files/folders, but will make sure that the one person handling htese knows NOT to make any such moves. In the meantime, I will cross my fingers and hope that the changes I applied tonight have fixed the problems. Many, many thanks.
    8,035 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following