NTFS Permissions and Share Permissions: 7 Secure File Server Rules

NTFS permissions and share permissions both control access to a Windows file share, and when a user connects over the network Windows applies the more restrictive of the two. This guide sets out the model we recommend for Windows Server 2025 and 2022 file servers: keep share permissions simple, do the real work in NTFS with domain local groups (AGDLP), script the setup with New-SmbShare and icacls, hide what users cannot open with access-based enumeration, and check the result with effective access.

Short answer: Give the share Authenticated Users: Change and Administrators: Full Control. Remove inheritance on the share’s root folder, then grant NTFS permissions only to domain local groups (for example Modify for a read-write group and Read & execute for a read-only group), with user accounts placed in global groups that are members of those domain local groups. Enable access-based enumeration with Set-SmbShare -FolderEnumerationMode AccessBased.

How share and NTFS permissions combine

Share permissions apply only to access through the SMB share. NTFS permissions apply to every access, over the network or at the console. For network access, Windows calculates each set separately and grants the most restrictive result.

Share permission	NTFS permission	Effective over the network
Change	Modify	Modify
Change	Read & execute	Read
Read	Modify	Read
Full Control	Full control	Full control, including changing permissions and taking ownership
Change	Full control	Modify: cannot change permissions over the share

Share permissions have only three levels (Read, Change, Full Control) and cannot differ between subfolders. NTFS permissions are granular and inherit down the folder tree, which is why they are the right place for the detail.

Which permission model to use

Model	Share permissions	NTFS permissions	Verdict
Recommended	Authenticated Users: Change; Administrators: Full Control	All detail, granted to domain local groups	One place to manage access; users cannot change ACLs over the network
Common alternative	Everyone: Full Control	All detail	Works, but users who own files can change their permissions through the share
Share-level only	Specific groups Read or Change	Left at defaults	Avoid: no per-folder control and local access is wide open
Both detailed	Groups per share	Groups per folder	Avoid: two lists to keep in sync; hard to troubleshoot

Prerequisites

• A Windows Server 2025, 2022 or 2019 member server with the File Server role service (Install-WindowsFeature FS-FileServer) and a dedicated NTFS or ReFS data volume, not the system drive.
• Rights to create groups in Active Directory, or a group management process that does.
• The Active Directory PowerShell module (RSAT) on the machine where you create groups.
• A test user in each access group, so you can confirm results before users arrive.

Rule 1: Design groups with AGDLP

AGDLP stands for Accounts go into Global groups, global groups go into Domain Local groups, and domain local groups receive Permissions. Global groups describe people (a department or role); domain local groups describe access to one resource.

Layer	Example	Contains
Accounts	j.khan, a.patel	Users
Global group	GG_Finance, GG_Auditors	User accounts
Domain local group	DL_FS01_Finance_RW, DL_FS01_Finance_RO	Global groups (also from trusted domains)
Permission	NTFS ACL on D:\Shares\Finance	Domain local groups only

With this model you never touch the ACL again once it is set. Giving the auditors read access is a group membership change (GG_Auditors into DL_FS01_Finance_RO), which is quick, auditable and does not need a recursive permission change over millions of files.

New-ADGroup -Name "DL_FS01_Finance_RW" -GroupScope DomainLocal -GroupCategory Security -Path "OU=Resource Groups,DC=contoso,DC=com"
New-ADGroup -Name "DL_FS01_Finance_RO" -GroupScope DomainLocal -GroupCategory Security -Path "OU=Resource Groups,DC=contoso,DC=com"
Add-ADGroupMember -Identity "DL_FS01_Finance_RW" -Members "GG_Finance"
Add-ADGroupMember -Identity "DL_FS01_Finance_RO" -Members "GG_Auditors"

Users pick up new group memberships at their next sign-in, so test with a fresh logon.

Keep the naming scheme predictable: prefix, server, share or folder, and access level. Put a description on each domain local group that names the exact path it controls, and give each resource group an owner in the Managed by field. When the share moves to another server or into a DFS namespace, you create new domain local groups for the new path and nest the same global groups, and nothing changes for users.

Rule 2: Create the share with simple permissions

PowerShell

New-Item -Path "D:\Shares\Finance" -ItemType Directory
New-SmbShare -Name "Finance" -Path "D:\Shares\Finance" -FullAccess "BUILTIN\Administrators" -ChangeAccess "NT AUTHORITY\Authenticated Users" -FolderEnumerationMode AccessBased -CachingMode None -Description "Finance department data"
Get-SmbShareAccess -Name "Finance"

To adjust share permissions later:

Grant-SmbShareAccess -Name "Finance" -AccountName "CONTOSO\DL_FS01_Finance_RW" -AccessRight Change -Force
Revoke-SmbShareAccess -Name "Finance" -AccountName "Everyone" -Force

-AccessRight accepts Full, Change and Read. Add -EncryptData $true to New-SmbShare if the data must be encrypted in transit; clients need SMB 3.0 or later.

Server Manager

1. Open Server Manager » File and Storage Services » Shares and choose Tasks » New Share.
2. Pick SMB Share – Quick, select the volume or type a custom path, and name the share.
3. On Other Settings, tick Enable access-based enumeration.
4. On Permissions, click Customize permissions to set both the share and the NTFS permissions from one dialog.

A share name ending in $ (for example Finance$) is hidden from browse lists. That is convenience, not security: anyone who knows the name can connect if the permissions allow it.

Rule 3: Set NTFS permissions with icacls

New folders inherit the volume’s default ACL, which includes entries such as Users: Read & execute and CREATOR OWNER. Replace that with an explicit ACL on the share root:

icacls "D:\Shares\Finance" /inheritance:r
icacls "D:\Shares\Finance" /grant:r "BUILTIN\Administrators:(OI)(CI)F" "NT AUTHORITY\SYSTEM:(OI)(CI)F"
icacls "D:\Shares\Finance" /grant "CONTOSO\DL_FS01_Finance_RW:(OI)(CI)M" "CONTOSO\DL_FS01_Finance_RO:(OI)(CI)RX"
icacls "D:\Shares\Finance"

/inheritance:r removes inherited entries, and /grant:r replaces any existing explicit entry for that account. The simple rights are F (Full), M (Modify), RX (Read & execute), R (Read), W (Write), D (Delete) and N (No access).

Inheritance flags

Flag	Meaning	Typical use
(OI)	Object inherit: files below inherit the entry	Almost always, with (CI)
(CI)	Container inherit: subfolders inherit the entry	Almost always, with (OI)
(IO)	Inherit only: the entry does not apply to this folder	Rights for subfolders but not the root
(NP)	No propagate: only direct children inherit	List access one level down
(I)	Shown in output: the entry was inherited	Read-only indicator

Protect the top-level folder structure

With Modify on the root, users can rename or delete the department folders you created. On shares with a fixed structure, give the read-write group read on the root itself and Modify only below it:

icacls "D:\Shares\Finance" /grant:r "CONTOSO\DL_FS01_Finance_RW:RX"
icacls "D:\Shares\Finance" /grant "CONTOSO\DL_FS01_Finance_RW:(OI)(CI)(IO)M"

Users can then work inside Finance\Payables and Finance\Payroll, but cannot delete or rename those folders or save files at the root. Grant this to a separate subfolder only when you need a different audience; each break in inheritance is something the next admin has to discover.

Use the same model in PowerShell

$path = "D:\Shares\Finance\Payroll"
$acl = Get-Acl -Path $path
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("CONTOSO\DL_FS01_Payroll_RW","Modify","ContainerInherit,ObjectInherit","None","Allow")
$acl.AddAccessRule($rule)
Set-Acl -Path $path -AclObject $acl
(Get-Acl -Path $path).Access | Format-Table IdentityReference, FileSystemRights, IsInherited, InheritanceFlags -AutoSize

The standard permission levels

Level (icacls)	Allows	Give it to
Full control (F)	Everything, including changing permissions and taking ownership	Administrators and SYSTEM only
Modify (M)	Read, write, create and delete files and folders	Read-write groups
Read & execute (RX)	Open files, list folders and run programs	Read-only groups
Read (R)	Open files and list folders, without execute	Rarely needed on file shares
Write (W)	Create files and write data, without read	Drop-box folders only

Advanced rights such as RD (list folder / read data), AD (create folders / append data) and X (traverse folder) combine into custom entries, as the home folder example below shows.

Rule 4: Enable access-based enumeration

Access-based enumeration (ABE) hides files and folders that a user has no read permission for. Users see only what they can open, which cuts support calls and hides folder names such as Redundancies 2026 from people who should not know they exist.

Set-SmbShare -Name "Finance" -FolderEnumerationMode AccessBased -Force
Get-SmbShare -Name "Finance" | Select-Object Name, Path, FolderEnumerationMode

ABE depends entirely on accurate NTFS permissions: it hides items based on the ACL, it does not grant or block access itself. It is set per share, and on DFS namespaces it is enabled separately on the namespace. On folders with tens of thousands of items, listing a directory takes longer because the server checks each item for the user.

Rule 5: Check effective access

1. Open the folder’s Properties » Security » Advanced and select the Effective Access tab.
2. Click Select a user, choose the test user, and click View effective access.
3. Read the Access limited by column: it shows whether the share permissions or the file permissions restrict each right.

From PowerShell, compare the share and NTFS entries side by side:

Get-SmbShareAccess -Name "Finance" | Format-Table AccountName, AccessControlType, AccessRight
icacls "D:\Shares\Finance"
Get-ADPrincipalGroupMembership -Identity "j.khan" | Select-Object Name

Remember that the user’s access token was built at sign-in. After a group change, the user must sign out and in again (or you restart the client) before the new NTFS permissions apply.

Home and redirected folders

Per-user folders need a different pattern: users must be able to create their own folder at the root but not see anyone else’s. Grant the root these entries, with the share set to Authenticated Users: Full Control or Change:

icacls "D:\Shares\Home" /inheritance:r
icacls "D:\Shares\Home" /grant:r "BUILTIN\Administrators:(OI)(CI)F" "NT AUTHORITY\SYSTEM:(OI)(CI)F" "CREATOR OWNER:(OI)(CI)(IO)F"
icacls "D:\Shares\Home" /grant "CONTOSO\GG_Staff:(RD,AD,X,RA)"

The staff entry has no inheritance flags, so it applies to the root folder only: users can list the root and create a folder, and CREATOR OWNER then gives the creator full control of that new folder. Combined with ABE, each user sees only their own folder. Folder Redirection and the Home folder field in Active Directory both work with this layout.

Troubleshooting access problems

Symptom	Likely cause	Fix
User was added to the group but still gets access denied	Old access token	Sign out and in again; check with whoami /groups
Folder visible but cannot be opened	List right without read on the contents, or ABE disabled	Check the ACL with Effective Access; enable ABE
Admin on the server is prompted “You don’t currently have permission to access this folder”	UAC filters the Administrators group for local Explorer sessions	Do not click Continue (it adds your account to the ACL); open the folder via its UNC path or use an elevated PowerShell
ACL shows entries like S-1-5-21-...	Orphaned SIDs from deleted accounts or groups	Remove them with icacls <path> /remove <SID> /T after checking the backup
Read-only group can delete files	User is also in the read-write group through another nesting	Check Get-ADPrincipalGroupMembership and nested groups

Rule 6: Avoid the common mistakes

Mistake	Why it hurts	Do this instead
Granting permissions to individual users	Each change means editing ACLs; leavers stay in ACLs as orphaned SIDs	Grant to domain local groups only
Deny entries for Everyone or Domain Users	Deny wins over allow and also blocks admins who are members	Remove the allow instead; use Deny only for a narrow, documented exception
Full Control for users	Users can change permissions and take ownership	Modify is enough for normal work
Breaking inheritance deep in the tree	Hidden exceptions nobody remembers	Break inheritance at the share root or first level only
Moving files between folders on the same volume	Moved items can keep their old ACL instead of taking the target’s	Copy instead of move, or run icacls <path> /reset /T on the moved item
Relying on share permissions alone	Local and RDP users bypass them completely	Always set NTFS permissions
Changing ACLs on large trees in business hours	Recursive changes lock files and take a long time	Change group membership rather than ACLs; schedule recursive work

Rule 7: Back up ACLs and audit changes

Before any bulk change, save the NTFS permissions so you can roll back:

icacls D:\Shares\Finance\* /save C:\ACLBackup\finance-acl.txt /T /C
icacls D:\Shares\Finance\ /restore C:\ACLBackup\finance-acl.txt /C

/save stores the ACLs relative to the path you gave, so run /restore against the parent of what you saved. Keep the backup with your change record.

To see who changed a permission or deleted a file, enable Audit File System and add an auditing entry (SACL) to the share root. Event 4670 records permission changes and 4663 records deletes. Our file share auditing guide walks through the audit policy, the SACL and a PowerShell search.

Verify it works

1. Sign in as a read-write test user, open \\fs01\Finance, create, edit and delete a file in a subfolder.
2. Sign in as a read-only test user: files open but saving fails with access denied.
3. Sign in as a user in neither group: the share opens (share permission allows Authenticated Users) but shows no content, thanks to ABE and the NTFS permissions.
4. Run Get-SmbShare -Name Finance | Format-List * and icacls on the root, and save the output with the share’s documentation.

Once these checks pass, new access requests become group membership changes, and the NTFS permissions on the file server stay the same for years.

NTFS permissions at a glance

Official documentation: New-SmbShare, icacls, Set-SmbShare.

Related guides: File share auditing: find who deleted a file · Map Network Drives Group Policy: 2026 Item-Level Targeting Made Easy · DFS Namespaces and Replication: Reliable File Server Setup.

Frequently asked questions