How-to: Set Permissions for files and folders

Permissions can be set on Files and Folders with CACLS or XCACLS.

There are 4 types of group: Local Machine, Local Domain, Global Domain, Universal.

Create Local Users and Local Groups

Control Panel - admin tools - computer management - local users and groups
( not available on a Domain Controller )

or from the command line...
NET localgroup 

Create Global Domain groups and Local Domain groups

Control Panel - admin tools - Active directory users and computers - Users

or from the command line...
NET localgroup /domain
NET group /domain

Permissions that can be assigned

Permissions can be assigned to individual users or to groups. If a user has no rights to the files in a folder, then the security tab in the GUI will not appear (if you have no rights to even list the file names then you have no rights to list the security attributes either.)

Ownership of a file will override all access permissions - administrators can take ownership of any file. SUBINACL can change ownership from the command line.

Newly created files will be owned by the account used to create them (unless the account is an administrator).

Inheritance

In any filesystem, new files or folders that are added will automatically inherit permissions from their parent folder. When changing the permissions on a folder you will often want and expect those permissions to cascade onto all child items.

When setting up a large number of shared folders in a hierarchy you may consider assigning Everyone or Authenticated Users the List Files permission to the very top-level folder (the 'Teams' folder below). Also, an Administrator permission will be required (consider using a specific group for fileserver admins).

\Teams\Group1\
\Teams\Group2\
\Teams\Group3\

Common permissions can be applied and inherited from the top level to all the shared folders below. However, on a large fileserver, this can introduce a single point of failure - any change that is made to the top level permissions must cascade down to every file ACL that is set to inherit. On a very large/busy fileserver that inheritance process can take hours due to multiple file locks from open files. Changing thousands of ACLs on a live server can be a recipe for file-locking related 'Access Denied' errors even if the ACL changes are seemingly very minor.

Directly applying all permissions to each group folder and breaking inheritance will avoid that potential issue, but at the cost of some extra work when setting up new Group folders. There is no hard and fast rule on this, directly applied permissions have a little extra resilience, but inherited permissions are much easier to setup and manage.

In NTFS 5 the precedence of Inherited vs Directly Applied permissions is:

Explicit Deny ⭠ highest precedence
Explicit Allow
Inherited Deny
Inherited Allow ⭠ lowest precedence

So, a Directly Applied Allow permission will have precedence over an Inherited Deny permission.

Using inherited permissions with DFS and Access-based Enumeration has some limitations that you can read about here.

Summary attributes:

Friendly name	Access mask	Inheritance
Full control = Administer + Read/Write/Edit/Execute/Delete	FILE_ALL_ACCESS	(OI)(CI) OBJECT_INHERIT_ACE + CONTAINER_INHERIT_ACE
Modify = Read/Write/Edit/Execute/Delete	FILE_GENERIC_READ | FILE_GENERIC_WRITE | FILE_GENERIC_EXECUTE | DELETE	(OI)(CI) OBJECT_INHERIT_ACE + CONTAINER_INHERIT_ACE
Read and Execute	FILE_GENERIC_READ | FILE_GENERIC_EXECUTE	(OI)(CI) OBJECT_INHERIT_ACE + CONTAINER_INHERIT_ACE
List folder contents	FILE_GENERIC_READ | FILE_GENERIC_EXECUTE	(CI) CONTAINER_INHERIT_ACE
Read	FILE_GENERIC_READ	(OI)(CI) OBJECT_INHERIT_ACE + CONTAINER_INHERIT_ACE
Write	FILE_GENERIC_WRITE & READ_CONTROL	(OI)(CI) OBJECT_INHERIT_ACE + CONTAINER_INHERIT_ACE

Advanced view:

Friendly name	Access mask
Traverse Folder / Execute File	FILE_TRAVERSE & FILE_EXECUTE
List Folder / Read Data	FILE_LIST_DIRECTORY & FILE_READ_DATA
Read Attributes	FILE_READ_ATTRIBUTES
Read Extended Attriibutes	FILE_READ_EA
Create Files / Write Data	FILE_ADD_FILE & FILE_WRITE_DATA
Create Folders / Append Data	FILE_ADD_SUBDIRECTORY & FILE_APPEND_DATA
Write Attributes	FILE_WRITE_ATTRIBUTES
Write Extended Attributes	FILE_WRITE_EA
Delete Subfolders and Files *	FILE_DELETE_CHILD
Delete *	FILE_DELETE
Read Permissions	READ_CONTROL
Change Permissions	WRITE_DAC
Take Ownership	WRITE_OWNER

* “Delete Subfolders and Files” vs “Delete”
You can delete a file or subdirectory if you have either DELETE permission on the item or DELETE_CHILD permission on its parent.

To set up a directory where everybody can create files and can delete files that they have created, while still retaining the ability of an administrator/manager to delete any file:
Grant the DELETE_CHILD permission on the directory to the administrator/manager and also grant DELETE to CREATOR_OWNER as an inheritable attribute.
Each user who creates a new file will automatically become the creator/owner of that file and so will inherit the right to DELETE it.

Best Practice

A recommended arrangement is to assign file and print permissions with one set of groups (Resources), and assign user membership with a separate set of groups (Teams), then assign rights by making each team group a member of the relevant resource group(s).

Advantages
- No duplication of file ACLs no matter how many teams are granted access to the folder - this reduces the size of the File Allocation Table - less fragmentation of the FAT will improve file server performance.
- Avoid problems where an ACL change fails because some files are open/in use, with this arrangement, most administrative changes can be made by adding and removing Users from Team groups rather than editing ACLs on disk.
- You can view/audit all permissions in Active Directory without having to search through millions of file ACLs - this makes auditing easier.

“Of manners gentle, of affections mild; In wit a man, simplicity a child” ~ Alexander Pope

Related commands

How-to: Groups - Full description of AD Local Domain groups, Global and Universal groups.
How-to: Built-in Groups - Built-In Users and Security Groups.
NTRIGHTS - Grant account privileges.
File Security and Access Rights - docs.microsoft.com
Q271876 - Large Numbers of ACEs in ACLs Impair Directory Service Performance (slow logon times)
Q909264 - Naming conventions in Active Directory for computers, domains, sites, and OUs.