01
Confirm the approved users
Get the access list from the data owner. Decide whether normal collaborators need Read, Modify, or another level before touching the ACL.
Everyday IT · File Permissions
Preserve access before you restrict it.
Changing inherited permissions is one of those jobs that looks simple until the wrong entry is removed from the wrong folder.Build the approved access path first. Then change inheritance. Then prove both sides.
The safe sequence
The order matters more than the number of clicks.
02
Record the current ACL
Capture the existing permissions before changing anything. A rollback plan is much easier when you know exactly what existed beforehand.
03
Preserve administrative access
Confirm an approved administrative identity, SYSTEM, and any required backup, scanning, service, or application identities will retain the access they need.
04
Target the exact folder
Verify you are changing the intended child folder rather than a parent that controls a much larger part of the file structure.
05
Create or confirm the security group
Use a role-based security group for the approved users instead of building a list of one-off direct user permissions.
06
Grant the group before removing broad access
Add the approved group to the exact folder and verify the intended permission level before changing inheritance or removing inherited entries.
Changing inheritance without destroying the ACL
The dangerous shortcut is removing inherited permissions before the replacement access path exists.
Effective Access
Check before the change
Use Effective Access for an approved user and, where useful, an unapproved user. This gives you evidence about the current permission path before the design changes.
Inheritance
Convert before you clean up
When disabling inheritance on the target folder, converting inherited permissions into explicit permissions preserves the existing state while you make deliberate changes.
Cleanup
Remove only what you intend to remove
After the approved group and required administrative or service identities are preserved, remove only the broad entries that violate the new access requirement.
Avoid
Do not use broad Deny as a shortcut
Explicit Deny can interact with nested groups and other permission paths in surprising ways. Prefer a clean allow-based design unless the environment specifically requires Deny.
Remember: share and NTFS permissions combine
A correct NTFS ACL does not override a restrictive SMB share permission.
Share
Check the network share layer
If access works locally on the server but fails through the UNC path, review the share permission in addition to NTFS.
NTFS
Check inheritance and scope
Confirm the entry applies to the intended folder and child objects. Parent and child folders can have different effective results after inheritance is changed.
Token
Refresh group membership
A user added to a new security group may need to sign out and back in before the Windows logon token reflects the new membership.
Verification is part of the change
Do not stop because the ACL looks right in the dialog box.
Approved user
Test the real workflow
Open the exact network path and perform the actions the role requires. For Modify access, verify create, edit, save, rename, and delete behavior as appropriate.
Unapproved user
Prove the restriction
Use a valid test user outside the approved group and confirm the restricted folder cannot be browsed or opened beyond the intended design.
System path
Confirm services still work
Verify backup, scanning, application, or service identities that depend on the folder were not accidentally removed during the permission cleanup.
Preserve a known-good access path before changing the permission model.
Then prove both the user who should have access and the user who should not.
When to stop
Permission design can become infrastructure work quickly.
Escalate
The data owner or approved list is unclear
Do not invent the business access model from the ACL. Get ownership and authorization clarified first.
Escalate
Child folders have different exceptions
Complex inheritance, nested groups, or application-specific exceptions deserve a documented plan before broad propagation.
Escalate
No safe rollback exists
If you cannot preserve the current ACL or guarantee administrative recovery, stop before making the restrictive change.
Related Guides
Prove the permission boundary after the controlled change.
Verify allowed and denied access
Test the intended user workflow and an approved negative case before closing. Verify before close
Access is still denied
If group membership changed, refresh the token and inspect effective access before editing the ACL again. Test the group change
The boundary is unsafe or unclear
Stop and hand off the current ACL, inheritance state, rollback path, and unresolved access question. Escalate with evidence