Technical Case · KT-000005

Folder Access Was Wrong Because NTFS Inheritance Was Broader Than Intended

A child folder under a working SMB share inherited access from its parent, leaving a broad user group with more access than the business wanted.The share was not the problem. The access model failed at the NTFS inheritance layer.

Documented by Michael Miller Published September 7, 2026

Case ID

KT-000005

File Server / Permissions

Status

Resolved

Technologies

SMB / NTFS / Active Directory

Problem

What happened?

A folder beneath a broader network share inherited permissions from its parent. A broad security group therefore retained Modify access even though the business owner wanted only a defined set of users to continue using that folder.

The inherited entry could not simply be removed from the child as though it were a normal explicit ACE. The permission model had to be changed without accidentally removing administrative access, service dependencies, or the approved users' access.

Public-safe context

What was removed?

Customer identity

Organization, user, server, share, and folder names are omitted.

Production ACL names

Actual security-group names and account identifiers are generalized.

Business data

No filenames, document contents, credentials, or private paths are published.

Technical sequence

The actual permission-layer diagnosis, safe change sequence, and verification method are preserved.

Investigation

How was the failing layer proven?

Step 1

Inspect the exact child folder

The target folder's Advanced Security ACL was reviewed directly instead of assuming the parent share explained the access behavior.

Step 2

Separate SMB share permissions from NTFS

The network share itself was not changed. The unwanted access was traced to the file-system ACL on the child folder.

Step 3

Identify inheritance as the source

The broad Modify entry came from the parent and was inherited, which explained why it could not be removed as an isolated child-folder permission.

Step 4

Prove effective access before changing anything

Effective Access was checked for an approved user and an unapproved user, while administrative and SYSTEM access were also confirmed.

Change plan

How was access restricted safely?

Step 5

Create the approved access path first

A dedicated security group was used for the approved users and granted Modify on the exact folder before the broader inherited permission was removed.

Step 6

Convert inherited permissions to explicit entries

Inheritance was changed in a way that preserved the current ACL as explicit entries, allowing deliberate cleanup rather than a destructive reset.

Step 7

Remove only the unwanted broad entry

Once the approved group, administrators, SYSTEM, and required dependencies were preserved, only the broad access entry that violated the business requirement was removed.

Step 8

Propagate only where authorized

Child permission propagation was limited to the scope that had been approved instead of assuming the entire folder tree should inherit the new model.

Root Cause

What was actually wrong?

The problem was NTFS inheritance, not the SMB share

The child folder inherited a broad Modify permission from its parent. The effective access model therefore did not match the intended business boundary.

No separate share-permission fault was identified in the source record.

Verification

Effective Access showed the approved user retained Modify while the unapproved user no longer had NTFS access.

The approved user could create, edit, rename, and delete a test file. The unapproved user could not browse or open the restricted folder. Administrators and SYSTEM retained Full Control, and dependent application or backup workflows were checked after the change.

Lessons Learned

Permission troubleshooting is about the layer and the access model.

Do not change both share and NTFS permissions just because the symptom is access-related. Prove which layer actually controls the result.

This case was solved by identifying the inherited NTFS boundary, building the approved access path first, then changing inheritance and verifying both the positive and negative cases.

Related Resources

Turn the case into a repeatable method.

Flagship guide