Windows ICACLS and Permission Inheritance
When NTFS permissions get out of sync, one common culprit is broken inheritance. A folder (or file) has been set to “stop inheriting permissions” and now behaves differently from the rest of the tree. Last week I had to reset the inheritance on a folder and realized that it would be the perfect topic to write an article about. So, in this post, you’ll learn how to use the Windows icacls command to re‑enable inheritance on a single file, a single folder, or recursively on an entire folder tree, and the difference between ACLs and ACEs.
Understanding Windows ICACLS and Permission Inheritance
The Windows icacls command is a powerful tool to view, modify, and manage permissions (aka Access Control Lists – ACL) on files and folders. One common scenario in permission management is controlling inheritance — whether an object inherits permissions from its parent folder or maintains its own explicit permissions.
Inheritance ensures that permissions applied on a parent folder can automatically propagate to its child files and subfolders, simplifying administration. Sometimes, inheritance is disabled and needs to be re-enabled. In order to change the object’s inheritance you will need to run the commands below as an administrator, or with full ownership of the folders. Running the commands as a normal user may cause “Access is denied” errors, even if the commands are correct.
This table shows the icacls commands that are most commonly used. I highly encourage you to read the entire article to better understand what the commands are actually doing and see examples of how they are used. Remember, I am not responsible for the changes you make!
| Commands | Effect on inheritance | Effect on inherited ACEs |
|---|---|---|
icacls "Path" | Displays permissions as they currently exist | Displays permissions as they currently exist |
icacls "Path" /save "SavePath" | Saves permissions as they currently exist | Saves permissions as they currently exist |
icacls "Path" /inheritance:e | Enable inheritance on a file or folder | Starts inheriting from parent again |
icacls "Path" /inheritance:e /t | Enable inheritance recursively on folders and subfolders with files | Starts inheriting from parent again |
icacls "Path" /inheritance:d | Disable inheritance but keep current permissions explicitly | Converts inherited ACEs into explicit ones |
icacls "Path" /inheritance:r | Disable inheritance and remove inherited permissions | Removes inherited ACEs entirely |
Viewing Current Permissions and Inheritance
Before changing anything, show the current ACL to confirm whether inheritance is disabled.
icacls "C:\ExampleFolder"
- Entries marked with
(I)are inherited from a parent. - If you only see explicit entries and no
(I)flags, inheritance is likely disabled on that object.
Example snippet you might see when inheritance is working:
C:\ExampleFolder NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
CONTOSO\Domain Users:(I)(M)If those (I) indicators are missing at this level while present higher up the tree, someone has broken inheritance on this folder or file.
Backup ACLs Before You Touch Anything
Use “icacls /save” to capture your ACLs for rollback:
icacls "C:\ExampleFolder\Project" /save "C:\Temp\Project.acl" /t
That way, if anything goes wrong, you can restore the ACLs :
icacls "C:\ExampleFolder" /restore "C:\Temp\Project.acl"
Notice that if you are restoring ACLs on a subfolder, you restore the backup to a base folder that matches the stored paths. The name of actual .acl file can be anything you want or that makes sense for your environment.
With things backed up, now we’re ready to go make changes!
How to Re-enable Inheritance Using ICACLS
The icacls command supports three inheritance-related switches:
- Enable inheritance (re-enable permission inheritance from the parent) —
/inheritance:e - Disable inheritance and copy existing inherited permissions explicitly —
/inheritance:d - Disable inheritance and remove only inherited permissions —
/inheritance:r - Reset inheritance to permissions from its parent directory —
/reset
To re-enable inheritance on a file or folder, you use:
icacls "FullPathToFileOrFolder" /inheritance:e
Replace “FullPathToFileOrFolder” with the actual path of the file or folder you are working with.
Examples for Different Scopes
Enable Inheritance on a Single Folder or File
To re-enable inheritance only on a specific folder:
icacls "C:\ExampleFolder" /inheritance:e
Use this when you only want to fix one folder and leave children unchanged. As existing explicit permissions remain unchanged unless they conflict with what the parent applies.
To re-enable inheritance only on a specific file:
icacls "C:\ExampleFolder\File.txt" /inheritance:e
This makes “File.txt” inherit permissions again from “C:\ExampleFolder” (and ultimately from higher levels). The file will pick up any ACEs that are configured to flow down to files (container/object inherit flags). You can re-run icacls against just the file to look for “(I)” entries to confirm inheritance is active again.
Enable Inheritance on a Folder and All Its Subfolders and Files
This is the “fix the entire tree” scenario, and is useful when someone clicked “Disable inheritance” on a top‑level folder and has created a real mess. To recursively enable inheritance to a folder, all its subfolders, and files, use the “/t” (traverse) and “/c” (continue on errors) flags:
icacls "C:\ExampleFolder" /inheritance:e /t /c
This command makes sure inheritance is restored on the folder, all contained subfolders, and files, even if some files generate errors during processing. On large folder trees, this can take some time; so you can combine “/c” with “/q” to quiet the output:
icacls "C:\ExampleFolder" /inheritance:e /t /c /q
When to Use “/inheritance:d” vs “/inheritance:r”
It’s worth briefly discussing the other switches so we know when and how to use them, even if they are used less commonly.
/inheritance:d/inheritance:r
Reset Inheritance
Completely resetting inheritance is a powerful way to restore all of the default security settings on files and folders by resetting explicit ACLs back to the default ACLs inherited values from the parent folder object. This means any manually configured permissions will be removed, and the file/folder will inherit its’ permissions as if it were newly created in that location. It is commonly used to fix corrupted or undesired permissions by restoring the default inheritance and access settings.
icacls "C:\ExampleFolder" /reset /t /c /l
A couple things to know about using “/reset” is that you may need to take ownership first before resetting permissions, especially if access is denied. takeown /R /F "C:\ExampleFolder" And that resetting inheritance removes explicit permissions and can temporarily restrict access until the inheritance applies and you verify everything is correct. Depending on the size of your folder tree, this could take some time, so it’s better to perform this during off hours.
What are ACE and ACL?
An ACE (Access Control Entry) is an individual rule that defines the permissions granted or denied to a specific user or group (called a trustee) on a securable object like a file or folder. Each ACE contains crucial information such as a security identifier (SID) that identifies the trustee, an access mask specifying the allowed or denied rights (e.g., read, write, execute), and flags indicating whether the ACE applies to child objects through inheritance. ACEs control or audit access by specifying who can do what on an object and are the building blocks of ACLs.
An ACL (Access Control List) is a collection of ACEs associated with a securable object. It acts as an ordered list of these individual ACEs that collectively define the overall security policy for that object. For example, an ACL on a file might have several ACEs granting different users read or write permissions while denying others. There are two common types of ACLs:
- Discretionary ACL (DACL), which explicitly allows or denies access
- System ACL (SACL), which specifies audit rules for tracking access attempts
In short, the ACL is the overall list of permission entries, and each ACE within it is a discrete permission rule for a trustee on that object.
This relationship is fundamental in Windows NTFS security and is managed by tools like icacls, which modify the ACLs by adding, removing, or changing individual ACEs on files or folders.
Additional Notes
- Be sure to run the Command Prompt as Administrator to have sufficient privileges.
- The “/t” flag is essential for recursive application across all subfolders and files.
- Use “/c” to prevent the command from stopping on errors, which is useful for large directories.
- When inheritance is enabled, permissions from the parent folder’s ACL are applied automatically to children, marked with an “(I)” for inherited in permission listings.
Common Gotchas and Tips
- Inherited vs explicit permissions: Even after turning inheritance back on, explicit ACEs can still override or add to inherited permissions, so the ACL may not look perfectly “clean.”
- File‑only vs folder‑only inheritance: Flags like “(OI)” (object inherit) and “(CI)” (container inherit) control whether permissions flow to files, folders, or both, which explains why some files still differ.
- Locked or in‑use files: Using “/c” ensures the command continues even if a file is locked; errors will still be reported in the console.
- Combine with “takeown”: If a different owner prevents changes, scripts often pair “takeown” followed by “icacls /reset” or “/inheritance:e” to normalize problem trees.
I hope this guide and examples help you to understand how to use icacls to manage ACL inheritance on Windows systems effectively.
