During a file server migration, one of the more time-consuming tasks was rebuilding NTFS permissions on a folder structure. Doing this manually in the GUI would have worked, but it would also have been slow, repetitive, and easy to misconfigure. PowerShell turned out to be the better option because it allows the permission model to be defined once and applied consistently.
NTFS permissions are not always as simple as they first appear. Besides the basic access rights, there are inheritance settings and propagation flags that control how permissions are inherited by subfolders and files. Once those concepts are understood, PowerShell becomes a very clean way to manage folder security in a repeatable and auditable manner.
How the script works
The script starts by defining the target folder and loading its current ACL with Get-Acl. That ACL is the permission structure already attached to the folder. Instead of replacing everything immediately, the script reads the existing ACL first, modifies it, and then writes it back.
Next, two security groups are defined: one for modify access and one for read-only access. These are then turned into FileSystemAccessRule objects. That is the actual permission entry that Windows understands. Each rule includes the group name, the permission level, the inheritance flags, the propagation flags, and whether the rule is allowed or denied.
After that, inheritance is disabled with SetAccessRuleProtection($true, $false). The first parameter blocks inherited permissions from the parent folder. The second parameter removes the inherited rules that already exist on the folder. This is important in migration scenarios, because it gives you a clean folder ACL instead of keeping unwanted inherited entries.
Finally, the new rules are added to the ACL and saved back to the folder with Set-Acl.
Inheritance and propagation
The most important part of the script is the way it handles inheritance and propagation. The inheritance flags used here are ContainerInherit,ObjectInherit. This means the permission is passed on to both subfolders and files. In practical terms, the group that receives the permission on the top folder also keeps that permission throughout the folder tree.
The propagation flag is set to None. That means there is no special restriction on how the rule is inherited. The permission behaves normally and is applied to child containers and objects based on the inheritance flags. For a shared data folder, this is usually the desired behavior because users need consistent access to everything beneath the folder.
These two concepts are easy to mix up. Inheritance decides whether a rule is passed down. Propagation decides how it behaves when it is passed down. If either one is set incorrectly, the folder may look right at first but behave incorrectly in subfolders or on files.
Why this approach is useful
This script is useful whenever a folder structure needs to be rebuilt in a clean and controlled way. That can happen during a file server migration, when preparing a new departmental share, or when standardizing access permissions across multiple folders. Once the script is written, it can be reused instead of manually recreating the same permissions over and over again.
It also improves clarity. The permission model is visible directly in the script, which makes it easier to document, review, and troubleshoot later. That is a major advantage over manual permission changes in the GUI, especially in larger environments.
Git repository
The script is available here: GitHub repository