How to Set Up a File Server with Proper NTFS and Share Permissions

File server permissions go wrong in a predictable way. Someone cannot open a folder, so a permission gets added directly to that folder for that person. Repeat for three years and you have a structure nobody understands, an audit you cannot pass, and a migration that becomes a project in its own right.

The fix is not complicated, but it does have to be applied from the start. This guide covers how the two permission systems interact, the group model that keeps it manageable, and the specific settings to get right on a new share.

The two permission systems

Share permissions apply only when the folder is accessed over the network. They are coarse. Read, Change, Full Control, and they do not apply at all to someone logged on to the server locally.

NTFS permissions live on the file system itself. They apply regardless of how the file is reached, they are far more granular, and they inherit down the tree unless you stop them.

When a user connects over the network, Windows evaluates both and grants the more restrictive result. Share permission of Read with NTFS Full Control gives Read. Share Full Control with NTFS Read gives Read.

This is why the modern convention is to stop trying to manage two systems at once: set the share to Everyone, Full Control, and do everything meaningful in NTFS. It sounds alarming and is not. The share is wide open only in the sense that it defers entirely to NTFS.

The AGDLP model, and why it is worth the extra step

AGDLP stands for Accounts into Global groups, Global groups into Domain Local groups, and Permissions applied to the Domain Local group. It is one more layer than most people want, and it is what keeps a file server manageable at scale.

The payoff comes when someone asks who can write to a folder. You look at one group. It also means access reviews are a group membership export rather than a folder-by-folder crawl, and a migration to new hardware carries permissions across cleanly.

Permission levels. What to actually grant

Modify is the right answer for the vast majority of team folders. Full Control should be limited to administrators, because it includes the ability to change permissions. Which is how structures drift.

Building the share

# Create the folder and share it with PowerShell
New-Item -Path "D:\Shares\Finance" -ItemType Directory
New-SmbShare -Name "Finance" -Path "D:\Shares\Finance" -FullAccess "Everyone"

# Enable access-based enumeration so users only see what they can open
Set-SmbShare -Name "Finance" -FolderEnumerationMode AccessBased -Force

# Apply NTFS permissions to the domain local group
$acl = Get-Acl "D:\Shares\Finance"
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("CORP\DL-Finance-Data-Modify","Modify","ContainerInherit,ObjectInherit","None","Allow")
$acl.SetAccessRule($rule)
Set-Acl "D:\Shares\Finance" $acl

# Review what is applied
Get-Acl "D:\Shares\Finance" | Format-List AccessToString

Access-based enumeration is worth turning on everywhere. It hides folders a user cannot open rather than showing them and refusing entry, which removes a whole class of support call and quietly improves security by not advertising the structure.

Inheritance. The thing to understand before you break it

By default a new folder inherits permissions from its parent, and that is what you want almost all the time. Breaking inheritance to make one subfolder more restrictive is a legitimate and occasionally necessary thing to do. Doing it casually, repeatedly, at several levels, is how file servers become unmanageable.

If you must break it, do it at one clearly documented level, usually the top of a department tree, and keep everything below inherited. When you break inheritance Windows offers to copy the existing permissions or remove them; copy them, then edit, unless you are certain you want to start from nothing.

Five mistakes worth avoiding

• Assigning permissions to individual users. In a year nobody will know why Dave has access to the payroll folder.
• Using Deny to solve a problem. Deny beats every Allow and produces access failures that are genuinely hard to trace. Remove the group membership instead.
• Granting Full Control to users. They can then change permissions, and eventually will.
• Nesting shares inside shares. The effective permission calculation becomes something nobody can reason about.
• Not turning on access-based enumeration. It costs nothing and prevents a great many support calls.

Checking effective access

Right-click the folder, Properties, Security, Advanced, then the Effective Access tab. Enter a user and it tells you what they actually get after every group, inheritance rule and Deny entry has been evaluated. It is far more reliable than reasoning about it yourself, and it is the first thing to reach for when someone says they cannot open something.

Glossary

Frequently asked questions

Should share permissions be set to Everyone Full Control?

Yes, as the modern convention, with all real control applied through NTFS. Managing two permission systems in parallel produces confusion without adding security, since the most restrictive of the two always wins anyway.

Why can a user still open a folder after I removed them from the group?

Their access token still holds the old group membership. They need to sign out and back on, or the token needs to expire. This catches people out constantly during testing.

When should I use Deny?

Rarely, and only where you cannot achieve the outcome by removing group membership. Deny overrides all Allow entries and makes troubleshooting considerably harder for whoever inherits the server.

Is Modify or Full Control right for a team folder?

Modify. Full Control additionally allows users to change permissions and take ownership, which is how carefully designed structures gradually stop making sense.

How do I audit who has access to what?

Export group memberships rather than crawling folders. Which is the real reason for the AGDLP model. If permissions are only ever on domain local groups, a group membership report is a complete access report.

Disclosure: this post may contain affiliate links. If you buy through one of them, we may earn a small commission at no extra cost to you. We only recommend products we’ve tested or genuinely rate.