Understanding NTFS Permission Inheritance and Reading icacls Output

When you first look at NTFS permissions through icacls, the output can feel cryptic:

(CI)
	(OI)
	(IO)
	(NP)
	(I)

These short flags are not random. They are inheritance markers that tell Windows how a permission entry should behave. They answer questions like:

• Does this permission apply to the current folder?
• Should child folders inherit it?
• Should child files inherit it?
• Should inheritance stop after one level?
• Was this permission set here directly, or inherited from a parent?

Once you understand these flags, reading icacls output becomes straightforward.

This guide explains the meaning of each flag, how they combine, how to read real icacls output, and common misconfiguration mistakes that lead to security issues.

Why Inheritance Flags Exist

Windows uses ACLs (Access Control Lists) to manage permissions on files and folders. Each ACL contains one or more ACEs (Access Control Entries). Each ACE specifies:

• Who gets access (the principal)
• What access they get (the permission)
• Where that access applies (the inheritance scope)

The "where" part is where inheritance flags come in.

Without inheritance, administrators would need to manually set permissions on every subfolder and every file. That would be inefficient and error-prone. Inheritance lets a parent folder pass permissions down to the objects inside it automatically.

The Meaning of Each Flag

(CI) - Container Inherit

CI stands for Container Inherit. In NTFS terminology, a container is a folder. If a permission entry has (CI), child folders can inherit that permission.

• Applies to child folders
• Does not by itself apply to child files

Memory trick: CI = Containers = folders

(OI) - Object Inherit

OI stands for Object Inherit. In NTFS terminology, an object is a file. If a permission entry has (OI), child files can inherit that permission.

• Applies to child files
• Does not by itself apply to child folders (though folders do receive a silent inherit-only copy to propagate the ACE deeper - more on this below)

Memory trick: OI = Objects = files

(IO) - Inherit Only

IO stands for Inherit Only. This means the ACE does not apply to the current object itself. It exists only so that child objects can inherit it.

• Not used on the current folder or file
• Only passed down to children

Memory trick: IO = not here, only below

(NP) - No Propagate Inherit

NP stands for No Propagate Inherit. This limits how far inheritance can travel. The permission is inherited by direct children, but those children do not keep passing it onward to their own children.

• Inherit once
• Then stop

Memory trick: NP = next level only, no further propagation

(I) - Inherited

(I) means the ACE was inherited from a parent folder. This is not an instruction like CI or OI. It is a status marker.

• This ACE was not set directly here
• It came from a parent

Memory trick: I = inherited from above

The Two Most Important Flags: CI and OI

Most confusion comes from CI and OI, so it helps to see them with a concrete example.

Suppose you have this folder:

C:\Data
	|
	|-- Reports\
	|-- Backups\
	|-- notes.txt
	|-- config.ini

Inside C:\Data there are two kinds of children:

• Folders: Reports, Backups
• Files: notes.txt, config.ini

The distinction is simple:

• CI targets child folders
• OI targets child files

Case 1: CI Only

Suppose this ACE exists on C:\Data:

Team:(CI)(M)

This means:

• Team gets Modify
• Child folders inherit it
• Child files do not inherit it

Given this structure:

C:\Data
	|
	|-- Reports\
	|   |-- Jan\
	|   |-- report1.docx
	|
	|-- Backups\
	|-- notes.txt

The effect:

Key idea: CI affects child folders at all levels, but never child files.

Case 2: OI Only

Suppose this ACE exists on C:\Data:

Team:(OI)(R)

This means:

• Team gets Read
• Child files inherit it
• Child folders do not directly use it

Given the same structure:

C:\Data
	|
	|-- Reports\
	|   |-- Jan\
	|   |-- report1.docx
	|
	|-- Backups\
	|-- notes.txt

The effect:

Key idea: OI affects child files at all levels of the tree. Folders do not use the permission themselves, but they silently carry the ACE downward so that files at any depth still inherit it. This propagation detail is often overlooked and causes confusion when administrators expect OI to only reach direct child files.

Case 3: OI and CI Together

Suppose this ACE exists on C:\Data:

Team:(OI)(CI)(R)

This means:

• Team gets Read
• Child folders inherit it (CI)
• Child files inherit it (OI)

Key idea: OI + CI means both files and folders inherit. This is the most common combination for "apply everywhere below."

Case 4: OI + CI + IO

Suppose this ACE exists on C:\Data:

Team:(OI)(CI)(IO)(R)

This means:

• Child folders inherit it
• Child files inherit it
• The current folder does not use it (IO)

Key idea: IO removes the current object from the equation. The ACE becomes a template for children only. This is extremely common in real-world ACLs - Windows frequently splits a principal's access into two ACEs: one for the folder itself and one inherit-only ACE for its children.

Case 5: OI + CI + NP

Suppose this ACE exists on C:\Data:

Team:(OI)(CI)(NP)(R)

This means:

• Child folders inherit it
• Child files inherit it
• Inheritance stops after the first level

Given this deeper structure:

C:\Data
	|
	|-- Reports\
	|   |-- Jan\
	|   |   |-- summary.docx
	|   |-- report1.docx
	|
	|-- notes.txt

Key idea: NP means direct children get the permission, grandchildren do not. Use NP when you want to limit the blast radius of a permission to a single level.

Case 6: (I) - Inherited from Parent

Suppose C:\Data\Reports shows:

Team:(I)(OI)(CI)(R)

This means:

• The ACE was inherited from a parent (I)
• Child files inherit it (OI)
• Child folders inherit it (CI)
• Permission is Read

Key idea:(I) is not telling Windows to inherit anything. It is telling you that inheritance already happened. It is a status flag, not an instruction.

A Plain Mental Model

You can think of these flags as routing instructions:

How to Read icacls Output

When you run:

icacls c:\windows

you are asking Windows to show the ACL on C:\Windows. Each line follows this pattern:

Principal : flags + permissions

Each ACE tells you three things:

1. Who the entry is for
2. Where it applies (inheritance flags)
3. What permission it grants

Example:

BUILTIN\Users:(RX)

• Principal: BUILTIN\Users
• Flags: None (no OI, CI, or IO)
• Permission: Read and Execute

Plain English: The Users group has Read and Execute on C:\Windows itself.

Compare with:

BUILTIN\Users:(OI)(CI)(IO)(GR,GE)

• Principal: BUILTIN\Users
• Flags: OI (child files), CI (child folders), IO (not this folder)
• Permission: Generic Read, Generic Execute

Plain English: This ACE exists only so that child files and child folders under C:\Windows inherit read/execute access for Users. It does not apply to C:\Windows itself.

Try it yourself - paste any icacls output into our free icacls Decoder tool. It breaks down every ACE into plain English: who has access, what permissions they hold, and how inheritance flags apply. No signup required.

Real-World Example: C:\Windows ACL

Here is typical icacls output for C:\Windows:

C:\> icacls c:\windows
	c:\windows NT SERVICE\TrustedInstaller:(F)
	           NT SERVICE\TrustedInstaller:(CI)(IO)(F)
	           NT AUTHORITY\SYSTEM:(M)
	           NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
	           BUILTIN\Administrators:(M)
	           BUILTIN\Administrators:(OI)(CI)(IO)(F)
	           BUILTIN\Users:(RX)
	           BUILTIN\Users:(OI)(CI)(IO)(GR,GE)
	           CREATOR OWNER:(OI)(CI)(IO)(F)
	           APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(RX)
	           APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(OI)(CI)(IO)(GR,GE)
	           APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(RX)
	           APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(OI)(CI)(IO)(GR,GE)

Let us walk through each principal.

TrustedInstaller

Entry 1:NT SERVICE\TrustedInstaller:(F)

• Full Control on C:\Windows itself.

Entry 2:NT SERVICE\TrustedInstaller:(CI)(IO)(F)

• Full Control, inherit-only, for child folders only (CI, no OI).
• Does not apply to C:\Windows itself (IO).

Notice there is no OI here, so this ACE targets child folders specifically. Child files under C:\Windows do not inherit Full Control from TrustedInstaller through this ACE. This is an intentional security design - individual system files are protected separately.

SYSTEM

Entry 1:NT AUTHORITY\SYSTEM:(M)

• Modify on C:\Windows itself.

Entry 2:NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)

• Full Control, inherit-only, for both child files (OI) and child folders (CI).

Why the difference? SYSTEM gets Modify on the Windows folder itself but Full Control on everything inside it. This is a deliberate split: the parent folder has slightly tighter permissions while child objects are fully accessible to the operating system.

Administrators

Entry 1:BUILTIN\Administrators:(M)

• Modify on C:\Windows itself.

Entry 2:BUILTIN\Administrators:(OI)(CI)(IO)(F)

• Full Control on child files and folders.

This follows the same pattern as SYSTEM: tighter permissions on the parent, broader permissions inherited by children. Administrators can modify the C:\Windows folder itself but have Full Control over objects inside it.

Users

Entry 1:BUILTIN\Users:(RX)

• Read and Execute on C:\Windows itself.

Entry 2:BUILTIN\Users:(OI)(CI)(IO)(GR,GE)

• Generic Read and Generic Execute, inherited by child files and folders.

Regular users can read and execute but cannot modify or write. This is the baseline for unprivileged access.

CREATOR OWNER

CREATOR OWNER:(OI)(CI)(IO)(F)

• Full Control, inherit-only, for child files and folders.

CREATOR OWNER is a special placeholder identity, not a real user or group. When a user creates a new file or folder inside C:\Windows, Windows replaces CREATOR OWNER with the actual creator's SID. The creator then receives Full Control over the object they created. This is important in shared directories where multiple users create content.

Application Packages

APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(RX)
	APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(OI)(CI)(IO)(GR,GE)

Same pattern as Users: Read and Execute on C:\Windows itself, plus inherited read/execute for children. These entries support the Windows application sandbox model (UWP/Store apps). The same applies to ALL RESTRICTED APPLICATION PACKAGES.

The Pattern You Should Notice

A very common pattern in icacls output is:

• One ACE for the current folder itself
• One separate ACE with (IO) for child inheritance

For example:

BUILTIN\Users:(RX)
	BUILTIN\Users:(OI)(CI)(IO)(GR,GE)

Together these mean:

• Users can read/execute on C:\Windows itself
• Users also inherit read/execute on all child files and folders

This is why you must always read all ACEs for the same principal together. Reading a single line in isolation will give you an incomplete picture.

A Worked Folder-Tree Example

Suppose inside C:\Windows you have:

C:\Windows
	|
	|-- System32\
	|-- Temp\
	|-- explorer.exe
	|-- notepad.exe

Now look at this ACE:

BUILTIN\Users:(OI)(CI)(IO)(GR,GE)

That is the clearest practical demonstration of OI and CI together.

Permission Abbreviations

In practice, (GR,GE) is a generic read/execute combination. The generic permissions map to sets of specific permissions defined by the object type.

A Compact Method for Reading Any icacls Line

For any line, ask four questions:

1. Who is this for? - the principal (e.g., BUILTIN\Users)
2. Does it apply here or only below? - no IO means here; IO means children only
3. Which children inherit it? - CI = folders, OI = files, both = everything
4. What permission is granted? - F, M, RX, GR, GE, etc.

Example:

BUILTIN\Administrators:(OI)(CI)(IO)(F)

1. Administrators
2. Children only (IO)
3. Both files and folders (OI + CI)
4. Full Control (F)

Result: Child files and child folders under this location inherit Full Control for Administrators.

Common Misunderstandings

"CI means the current folder uses the permission." Not necessarily. CI only says child folders can inherit it. The current folder uses it only if IO is absent.

"OI means every object inherits it." Not exactly. OI targets child files specifically. Folders receive a silent inherit-only copy to propagate it, but they do not use the permission themselves (unless CI is also present).

"IO means the ACE is useless." Wrong. IO is extremely useful. It means the ACE is a template for child inheritance. Most real-world ACLs rely heavily on IO entries.

"(I) means 'inherit this now.'" Wrong. (I) means the ACE already came from a parent. It is a status flag, not a directive.

"NP means no inheritance at all." Wrong. NP allows inheritance to direct children, but blocks further propagation beyond them.

Common Misconfiguration Mistakes

Understanding the flags is one thing. Using them safely is another. Many NTFS permission problems are caused by small administrative mistakes that compound over time.

Mistake 1: Granting Full Control When Modify Is Enough

A common mistake is granting:

Team:(OI)(CI)(F)

when the actual need is only:

Team:(OI)(CI)(M)

Why this is risky:

• Full Control includes the ability to change permissions and take ownership
• Users can lock out administrators or alter the access model
• An attacker who compromises a user account inherits the ability to re-ACL the entire tree

Safer approach: Use the minimum required permission. Modify allows users to create, edit, and delete files without granting control over the ACL itself. Reserve Full Control for administrators who genuinely need to manage permissions.

Mistake 2: Breaking Inheritance Too Often

Administrators sometimes disable inheritance on many subfolders because of one special case.

D:\Data
	|-- HR\            (inheritance broken)
	|-- Finance\       (inheritance broken)
	|-- Engineering\   (inheritance broken)
	|-- Temp\          (inheritance broken)
	|-- Archive\       (inheritance broken)

Why this is risky:

• Permissions become impossible to audit at scale
• Parent and child behavior becomes unpredictable
• Future administrators cannot determine which folders are special
• Troubleshooting turns into a folder-by-folder manual inspection

Safer approach: Keep inheritance enabled wherever possible. Break it only for clearly justified exceptions, and document the reason when you do. A well-designed group structure at the parent level often eliminates the need to break inheritance.

Mistake 3: Misunderstanding IO and Assuming the Parent Is Protected

An administrator creates:

Team:(OI)(CI)(IO)(M)

and assumes Team also has Modify on the parent folder.

That is wrong. Because of IO, the ACE does not apply to the parent - it only serves as an inheritance template for children.

What goes wrong:

• Users cannot access the parent folder as expected
• Administrators think inheritance is broken when it is actually working correctly
• Share browsing or folder traversal fails unexpectedly

Safer approach: If users need access to both the parent and its children, you typically need two ACEs:

Team:(RX)
	Team:(OI)(CI)(IO)(M)

The first grants traverse/read access to the parent. The second provides Modify to everything inside it. Always ask: Do I need access on the current folder, the children, or both?

Mistake 4: Using CI When Files Also Need Access

An administrator creates:

Team:(CI)(M)

thinking this grants Modify to everything below.

It does not. CI only reaches child folders. Files do not inherit this ACE.

What goes wrong:

• Users can enter subfolders
• But files inside those folders may not have the required permissions
• Administrators see "I can open the folder but cannot edit the file" scenarios

Safer approach: If both folders and files should inherit, use:

Team:(OI)(CI)(M)

Mistake 5: Using OI When Folders Also Need Access

The reverse mistake. An administrator creates:

Team:(OI)(R)

thinking all children inherit Read.

Files do inherit, but folders do not use the permission (they only carry it silently for propagation). Users cannot enter subfolders because the folders themselves lack the Read permission.

What goes wrong:

• Files may be readable
• But users cannot traverse into deeper subfolders
• The ACL appears inconsistent even though it is behaving exactly as configured

Safer approach: Use OI and CI together when both files and folders need the permission.

Mistake 6: Assigning Permissions to Individual Users Instead of Groups

Administrators sometimes set ACLs like:

Alice:(M)
	Bob:(M)
	Charlie:(RX)
	David:(F)

instead of assigning permissions to security groups.

Why this is risky:

• ACLs become unwieldy as the team grows
• Onboarding and offboarding require editing ACLs across many folders
• Audits become painful - you must check every folder for stale entries
• Departed users retain access until someone manually removes their ACE

Safer approach: Use group-based access:

HR_Modify:(M)
	Finance_ReadOnly:(RX)

Then manage access by adding or removing users from groups, not by editing ACLs.

Mistake 7: Conflicting Share Permissions and NTFS Permissions

On file servers, administrators sometimes configure share permissions and NTFS permissions inconsistently:

• Share permission = Everyone Full Control, NTFS = tightly restricted
• Or the reverse: share permission too restrictive, NTFS broader

Effective access is the intersection of both. A user must be allowed by both the share permission and the NTFS permission to gain access.

What goes wrong:

• Users get "Access Denied" even though the NTFS ACL looks correct
• Administrators troubleshoot the wrong layer
• Environments drift into undocumented behavior

Safer approach: Adopt a consistent model. A common approach is:

• Share permissions kept broad (e.g., Authenticated Users - Change or Full Control)
• NTFS used for all detailed access control

The key is consistency and documentation. Pick one layer for fine-grained control and keep the other permissive enough not to interfere.

Mistake 8: Misunderstanding CREATOR OWNER

Administrators see:

CREATOR OWNER:(OI)(CI)(IO)(F)

and either ignore it or misunderstand it.

Common misconceptions:

• Thinking CREATOR OWNER is a real group with members
• Thinking it grants global rights to everyone
• Not realizing that in shared write locations, the creator of a file gets Full Control over it

Why it matters: In collaborative directories (e.g., shared project folders, temp directories), CREATOR OWNER determines whether users can manage the files they create. If removed, users may be unable to delete or rename their own files. If left in place without understanding, users may have more control than intended.

Safer approach: Understand that CREATOR OWNER is a placeholder resolved at object creation time. Review whether it is appropriate for each shared directory's use case.

Mistake 9: Using Deny ACEs Too Casually

Administrators sometimes add Deny ACEs to quickly "fix" an access problem.

Why this is risky:

• Deny overrides Allow - a Deny ACE on any group the user belongs to will block access, even if another group grants it
• Inherited Deny ACEs can spread through the tree in unexpected ways
• Troubleshooting becomes extremely difficult because the deny may come from a nested group membership
• Users lose access in places administrators did not anticipate

Example problem:

Marketing_Team:(OI)(CI)(M)        ← Allow: Modify for Marketing
	Contractors:(OI)(CI)(D)(DENY)     ← Deny: Delete for Contractors

If a marketing team member is also in the Contractors group, they lose delete access - even though Marketing was granted Modify (which includes delete). The Deny wins.

Safer approach: Avoid Deny ACEs unless genuinely necessary. Design clean Allow-based group models instead. If you must deny, document it clearly and test with representative user accounts.

Mistake 10: Permission Sprawl Through Nested Groups

Over time, organizations accumulate:

• Old security groups nobody maintains
• Deeply nested group memberships
• Copied folder trees with legacy ACLs
• Manually added exceptions
• Inherited entries from decommissioned structures

An ACL may look small, but effective access may come from many indirect sources.

What goes wrong:

• Nobody knows why a user has access
• Removing one ACE does not fix the issue because access comes through another path
• Inherited permissions from higher-level folders remain unnoticed

Safer approach: Regularly review group memberships, nested group design, high-level parent ACLs, inheritance breaks, and stale folders copied from old projects. Tools like AccessChk from Sysinternals or the Effective Access tab in Windows Security properties can help surface the real picture.

Mistake 11: Copying Folders Without Reviewing Permissions

A team copies a folder tree from one department to another and assumes the permissions match the new purpose.

What goes wrong:

• Explicit and inherited ACEs travel with the copy
• Former teams retain access to the new folder
• Sensitive data inherits the wrong permission structure
• Administrators assume the new folder is clean because the name changed

Safer approach: Whenever sensitive folders are cloned or repurposed, review explicit ACEs, inherited ACEs, broken inheritance, ownership, and share settings. Consider resetting permissions on the copy to match its new context.

Mistake 12: Not Testing Effective Access

Administrators often inspect the ACL visually and assume they know the outcome. But effective access is influenced by:

• Direct and inherited ACEs
• Group memberships (including nested groups)
• Deny entries
• Share permissions
• Object ownership
• Privilege assignments (e.g., SeBackupPrivilege can bypass ACLs)

What goes wrong:

• Configuration looks correct on paper
• Real users still get "Access Denied"
• Or worse, real users have more access than expected

Safer approach: Always test with a representative user account, realistic group membership, and the exact access path the user will take. In security-sensitive environments, do not rely on visual inspection alone. Use the Effective Access tab or tools like AccessChk to verify.

Warning Signs of a Bad NTFS Permission Design

If you see these signs, the ACL model likely needs a thorough review:

• Many explicit ACEs on deep subfolders
• Permissions assigned directly to individuals instead of groups
• Frequent broken inheritance with no documentation
• Widespread use of Full Control where Modify would suffice
• Administrators are afraid to touch ACLs because nobody understands them
• Access issues are "fixed" by adding more ACEs instead of simplifying
• Copied project folders carry unknown legacy permissions
• Deny ACEs are used as quick patches

A Simple Practical Design Mindset

A healthy NTFS permission model follows these principles:

1. Assign access to groups, not individuals
2. Keep inheritance enabled by default
3. Use parent folders to distribute permissions downward
4. Break inheritance only when necessary - and document why
5. Prefer Modify over Full Control unless there is a genuine need
6. Review copied folders before using them in a new context
7. Test effective access, not just visible ACEs
8. Audit regularly - groups, nested memberships, and high-level ACLs

Quick Reference

Best memory trick:

• C in CI = Containers = folders
• O in OI = Objects = files
• IO = not here, only below
• NP = next level only
• I = inherited from parent

Conclusion

NTFS inheritance looks complicated only until you separate the concepts. At the core:

• CI targets child folders
• OI targets child files
• IO means the current object does not use the ACE
• NP limits inheritance depth to one level
• (I) tells you the ACE came from a parent

When reading icacls, parse each line as:

identity : where it applies : permission

So BUILTIN\Users:(RX) means Users have Read/Execute on this folder, and BUILTIN\Users:(OI)(CI)(IO)(GR,GE) means child files and folders inherit Read/Execute for Users.

Most NTFS permission failures are not caused by mysterious Windows behavior. They come from a few recurring mistakes: confusing CI and OI, using IO without realizing it excludes the parent, granting Full Control too broadly, breaking inheritance without documentation, assigning permissions to individual users, and piling new ACEs onto an already messy ACL.

If you understand inheritance and keep the permission model simple, group-based, and documented, NTFS becomes far easier to manage and far safer to operate.