Network File Permissions Basics (NTFS and SharePoint)

This post contains affiliate links. If you purchase through our links we may earn a small commission at no extra cost to you.

Network file permissions are the invisible plumbing that decides who can open what file. Get them right and everyone accesses exactly what they need, security-conscious owners sleep at night, and auditors leave satisfied. Get them wrong and you either have HR files accidentally readable by the whole company (career-ending mistake for the IT lead) or users constantly locked out of files they need to do their jobs (help desk tickets forever). This guide covers the two permission systems small businesses actually deal with: NTFS permissions on Windows file servers, and SharePoint permissions in the cloud. Same conceptual model — folder inheritance, groups, principle of least privilege — but different mechanics that trip up people who assume they work identically.

Why permissions matter

Every file share failure comes back to permissions. Users can see files they shouldn’t (compliance risk), can’t see files they should (productivity killer), or can accidentally delete/modify critical documents (data loss). Correct permissions design prevents all three.

Permissions also matter for cybersecurity. Ransomware that hits a single user encrypts only what that user could access. Overly-broad permissions = ransomware encrypts everything.

Core concepts (apply to both systems)

Users, groups, and permissions

• Users are individual accounts ([email protected])
• Groups are collections of users (Finance-Team, All-Employees, Contractors)
• Permissions are assigned to users or groups on folders/files

Best practice: assign permissions to groups, not individual users. When Jane joins Finance, add her to Finance-Team; don’t manually add her to 47 folder permissions.

Inheritance

Permissions applied to a folder cascade down to subfolders and files by default. This is the mechanism that makes managing thousands of files practical — set permissions at the top level, everything below inherits.

Breaking inheritance (making a subfolder have unique permissions) is where confusion starts. Only break inheritance when necessary; document when you do.

Principle of least privilege

Users get the minimum permissions needed to do their job. Not “read/write to everything.” Not “full control just in case.” Least privilege limits damage from mistakes and compromised accounts.

See our cross-cluster piece at SmallBizSecurityGuide’s least privilege guide for the security policy framing.

Deny vs allow

Both systems have “allow” (user gets access) and “deny” (user explicitly blocked). Deny overrides allow — if a user is in a group with allow but also in a group with deny, deny wins.

Best practice: avoid explicit denies. They create hard-to-troubleshoot situations. Prefer “not in the allow group” over “explicitly denied.”

NTFS permissions (Windows file server)

The six standard NTFS permissions

• Full Control: read, write, delete, change permissions, take ownership. Rarely needed for regular users.
• Modify: read, write, delete files. Common for “user has their own workspace” scenarios.
• Read & Execute: open files, run applications, browse folders
• List Folder Contents: browse folder structure without opening files
• Read: open files
• Write: create files (but not necessarily modify existing)

The AGDLP model

Active Directory best practice for NTFS permission management:

• Accounts (users) → placed into
• Global groups (based on job function: Finance-Users, Sales-Users) → placed into
• Domain Local groups (based on resource: FinanceShare-Read, FinanceShare-Modify) → assigned
• Permissions on the resource

Sounds complex but produces the cleanest permissions model. When Jane moves from Finance to Sales, remove her from Finance-Users, add her to Sales-Users. All permissions update automatically.

Share permissions vs NTFS permissions

Confusing for beginners: Windows file shares have TWO permission layers.

• Share permissions: applied at the share level (\\server\share). Simple: Read, Change, Full Control.
• NTFS permissions: applied at the folder/file level. Detailed as above.
• Effective permission: the most restrictive of share + NTFS

Best practice: set share permissions to “Everyone: Full Control” and manage all access via NTFS. Simpler and more powerful.

Common NTFS mistakes

• Adding “Everyone: Full Control” throughout — permission chaos
• Never removing “Domain Users: Read” on sensitive folders — HR/Finance data readable by all
• Assigning permissions to individual users instead of groups
• Breaking inheritance without documentation — nobody knows why 6 months later
• Using “Full Control” when “Modify” would work — allows accidental permission changes

SharePoint permissions

The permission model

• Site level: Owner, Member, Visitor (default groups; can be customized)
• Library level: can override site permissions
• Folder/file level: can override library permissions

Standard SharePoint permission levels

• Full Control: everything, including managing permissions
• Design: customize site and content
• Edit: add, edit, delete content and lists
• Contribute: add, edit, delete content but not lists
• Read: view only
• Limited Access: system-assigned when user has direct access to a subitem

M365 groups vs SharePoint groups

SharePoint sites in modern M365 are backed by Microsoft 365 Groups (which also drive Teams, Outlook groups, etc). Adding a user to the M365 Group grants membership everywhere. This is usually what you want.

SharePoint groups (Owners, Members, Visitors) are the older classic model, still functional.

Common SharePoint permission mistakes

• Sharing via direct email invites instead of adding to groups — creates permission sprawl
• Never auditing external sharing — old external users retain access to sensitive content
• Using “Everyone in Organization” for sensitive libraries
• Not disabling anonymous link sharing by default
• Breaking inheritance at file level for permissions that should be at library level

Recommended permission structure — typical 40-person business

Groups to create

• All-Employees (baseline access)
• Executive-Team
• Finance-Team
• HR-Team
• Sales-Team
• Marketing-Team
• Operations-Team
• IT-Admins
• Contractors (limited access baseline)

Folder structure with permissions

• Public/ — All-Employees: Read/Modify (company handbook, policies)
• Departments/Finance/ — Finance-Team: Modify, Executive-Team: Read
• Departments/HR/ — HR-Team: Modify (nobody else — sensitive)
• Departments/Sales/ — Sales-Team: Modify, Marketing-Team: Read
• Projects/ — per-project folders with project team membership
• IT-Admin/ — IT-Admins: Full Control (nobody else)

Simple. Predictable. Extensible. When new department launches, create Department-Name group and Department-Name folder — done.

Auditing permissions

Quarterly (minimum): audit who has access to what. Tools:

Windows NTFS

• PowerShell: `Get-Acl` commands to script permission enumeration
• Third-party tools: SolarWinds, Netwrix Access Auditor, ADManager Plus
• Free: AccessEnum from Sysinternals

SharePoint

• SharePoint admin center: Access Requests and Invitations reports
• Microsoft 365 Compliance: Access reviews for M365 groups
• PowerShell: Get-SPOSiteGroup, Get-SPOUser commands
• Third-party: ShareGate, AvePoint

Documentation is non-optional

Permissions without documentation = tribal knowledge that walks out the door when your IT person leaves. Maintain:

• Group definitions: what each group is for, who owns membership decisions
• Folder-to-group mapping: which folders each group has access to
• Exception log: any folders with unique/broken-inheritance permissions and why
• Access request procedure: how users request access, who approves

See our IT documentation runbooks guide for the broader documentation framework.

Common permission scenarios

New employee onboarding

1. Create user account (AD or Entra ID)
2. Add to All-Employees group
3. Add to department group based on role
4. Add to project-specific groups if applicable
5. No custom folder permissions needed — groups handle it

Contractor with limited access

1. Create contractor account (separate from employees for clarity)
2. Add to Contractors group only
3. Contractors group has access only to Public/ and specific project folders
4. Never add contractors to All-Employees or department groups

Executive needs to review a specific project

1. Do NOT add Executive to project group (creates precedent for permission sprawl)
2. Grant read access at that project folder specifically
3. Set calendar reminder to remove access when project ends

Employee changes departments

1. Remove from old department group
2. Add to new department group
3. All permissions update automatically
4. Audit for any individually-assigned permissions from old role

Migration considerations — NTFS to SharePoint

When migrating from file server to SharePoint (see our migration guide): don’t copy NTFS permissions directly. Rebuild for SharePoint model instead.

Why: NTFS permissions are per-folder and can be granular in ways SharePoint isn’t optimized for. Copying creates a permission mess. Redesigning from scratch produces a cleaner, more maintainable structure.

Recommended tools

• USB backup drives for permission audit exports — for offline audit trail archives
• Dedicated admin laptop for permission management — separates admin work from daily use

Related SBITG topics

Related infrastructure: AD vs Entra ID, Entra ID setup, M365 admin center basics. Storage decisions: SharePoint vs OneDrive vs Drive, file server to SharePoint migration. Documentation: IT runbooks and documentation. Cross-cluster (security lane): least privilege at SBSG, privileged access management at SBSG.

Key takeaways

• Manage permissions via groups, not individual users. Group membership = permission.
• NTFS: use AGDLP model (accounts → global groups → domain local groups → permissions on resource).
• SharePoint: use M365 Groups (backed by Teams/Outlook), avoid direct-share sprawl, audit external sharing quarterly.
• Set share permissions to “Everyone: Full Control” and manage access via NTFS — simpler than fighting both layers.
• Document every group, every folder mapping, every broken-inheritance exception. Undocumented = unmaintainable.

FAQ

Do I need to worry about NTFS permissions if I’m all on SharePoint? No, if truly 100% cloud. Yes, if you have any Windows file server (backup target, on-prem NAS, legacy system) — NTFS permissions still govern those. Most small businesses have some mix and need to understand both.

What’s the difference between “Change” and “Modify” permissions? “Change” is a Share permission (Read, Change, Full Control). “Modify” is an NTFS permission. Different systems, similar concept. If you follow the best-practice of Everyone-Full-Control at share level + granular NTFS, you’ll rarely deal with Change directly.

How often should I audit permissions? Minimum quarterly for standard files. Monthly for HR, Finance, or regulated data. Annually for public content. Any time an employee leaves (immediate audit of their access), any time you have a security incident (full audit).