Roan sez:

Security permissions for folders:

Read - Allows Listing the files in the folder Write - Allows creating files in the folder (but not deleting files in the folder) Delete - Allows deleting the folder (and ALL the files in the folder) Execute - Allows "traversing" (accessing contents) of the folder Change Permissions - Change the folder permissions allowed for each user/group Take Ownership - Change the owner of the folder

If you allow "Execute" permission then users can access subfolders and files (if the permissions of the subfolders and files allow that). If you do not allow "Execute" permission then no access is permitted to the contents of the folder or subfolders (ignoring permissions on things contained in the folder). The OS defaults to granting Everyone "Bypass traverse checking" rights so usually "Execute" has no effect. Change the security settings "Rights" to not give everyone "Bypass traverse checking" if you want to control access using "Execute" permissions on folders.

If you allow "Read" permission for folders, it is permitted to get a "directory" of the file names (not necessarily read the contents of the folder or files). Even if you grant a folder "Read" permission, users can't actually access the files unless they have the apropriate permissions ("Execute" for folder and "Read" for file).

Read - Allows reading the contents of the file and copying the file Write - Allows changing the contents of the file Delete - Allows deleting or renaming the file Execute - Allows executing the contents of the file (but not copying or reading) Change Permissions - Change the file permissions allowed for each user/group Take Ownership - Change the owner of the file

All of the permissions that I mentioned can be either "Granted" or "Denied" for any Users or Groups. You add the desired Users or Groups to the security settings for the folder or file, then change the permissions for those Users or Groups. You can also set folders and files to "inherit" permissions from the containing folder (that's the default).

Denying permissions always overrides granting permissions. If a user belongs to a group that is denied a permission then they are denied the permission even if you grant the same permission for that user. Most of the time you don't want to deny a permission. Use denying permissions carefully because there is no way to override any entries denying a user or group permissions.
Not granting a permission for a user or group (not checking the Grant box) will disallow the permission unless some other entry grants the permission for the user/group. Normally you just don't Grant a permission for users or groups that shouldn't have it.

There are two ways to control how files and folders inherit permissions from their parents. Folder permissions can specify which subfolders and files the permissions will "Apply To". Files or folders can choose to Inherit or not Inherit ALL permissions from parents.
Folder permissions can apply to these things contained inside the folder.

You can make any entry for a User or Group apply to one or more of the things that I mentioned. You can add the same User or Group multiple times with different "Apply To" settings. For example, you can have one set of permissions for a User apply to This folder and different permissions apply to Subfolders and Files. When you look at the "Apply To" information in Windows it is confusing because the three things are combined in one sentence.

How to use all this:

The best approach to folder and file permissions is to set permissions at as high a level in the folder tree as possible. That allows other files and folders to inherit most of the desired permissions. Where you need to change the default permissions below a folder, then change that folder's permissions and either add some or disable inheritance and create new permissions.

I also recommend that you generally use groups to apply permissions and not individual users. That makes it easier to keep track of what permissions a user has, and change them as their role changes. Even if you only think that one person needs a particular special access, create a group for that kind of access and then grant the access to the group.

Where you don't want users to see the names of files disallow "Read" access to a folder. If you don't want users to execute files in a folder and subfolders then allow the "Execute" permission for "This folder and subfolders" but disallow the "Execute" permission for "Files" in the folders.

Keep in mind that premissions for Files have a different meaning than permissions for Folders and Subfolders. You will often have two permission entries for each group or user. One permission entry will grant the desired File permissions and the other will grant the desired Folder/Subfolder permissions. In other cases you may have three permission entries for a group if the parent folder needs different permissions than subfolders.

You can make security permissions horribly complicated or you can keep them relatively simple by planning inheritance carefully. Try to avoid having to set the same permission on mutliple folders and files individually. When you find yourself doing that ask yourself if this permission can be inherited from the parent folders. If the only problem is a few exceptions to the rules consider making those exceptions NOT inherit permissions or explicitly deny permissions on those exceptions.

Experiment on some safe files and folders where you won't do any harm. It takes practice to get used to setting permissions and understand the effects of each permission. Test your permission settings after you think you have them correct because the effects of inheritance or denying permissions might not be obvious and might not work the way you intend.

Network Share permissions and file/folder permissions are separate. Anything NOT allowed by Share Permissions is not allowed when accessing folders and files through the share. You can disallow more permissions through a network share but you can't grant more permissions not already allowed by the folder/file permissions. Think of Share permissions as further restrictions on top of the folder/file permissions. Using groups for share permissions is a good idea too.

What does "owning" a file or folder really mean? An "owner" of a folder or file ALWAYS has the right to change permissions even if not granted, or explicitly denied that permission by the security entries. That's to keep the owner (or someone else) from making their own files inaccessible.

Administrators ALWAYS have the right to Take Ownership of a folder or file (but not necessarily change permissions). If a file or folder does not grant Administrators the right to change permissions then the Administrators have to Take Ownership of the folder or file to change permissions. Even if permission entries explicitly deny Administrators the right to Take Ownership they still ALWAYS have that right. It makes no sense to deny Administrators permissions since they can always get them by taking ownership of the files.

You may have seen the two security "principals" called CREATOR_OWNER and CREATOR_GROUP. Those allow you to specify the INITIAL permissions for the owner or owning group that creates a folder or file BEFORE you know exactly who that owner will be. Those permissions apply to whichever user (or group) actually creates the folder or file. Those only control the INITIAL permissions and if permissions are changed for the creating owner or group they will not be reset back to what "CREATOR_OWNER" or "CREATOR_GROUP" indicate. After a folder or file has been INITIALLY created those two security principals are ignored and don't affect permissions at all. Think of them as a permission template to set up the permissions for the owner. They can be very useful for folders where many different users will create other folders or files. You normally want to give CREATOR_OWNER full control over what they created.