Skip to content

Windows

File Sharing and Permissions

File sharing on Windows Server is built on SMB (Server Message Block). The single most important thing to understand is that two separate permission layers - Share and NTFS - both apply, and the more restrictive of the two wins.

Tested on

Windows Server 2022 with the File Server role (part of File and Storage Services). The workflow is identical on Windows Server 2019 and 2016.

SMB file shares

SMB is the protocol Windows uses to make a folder available over the network. When you "share a folder," you publish it under a share name that clients reach via a UNC path:

\\SERVER01\Finance          <- a share called "Finance" on SERVER01
\\SERVER01\Finance$         <- a hidden share (trailing $ hides it from browsing)

Windows Server 2022 uses SMB 3.1.1, which supports encryption in transit and signing. Prefer it; disable the legacy, insecure SMB 1.0 if it is still present (Get-WindowsFeature FS-SMB1).

Creating a share

GUI (Server Manager)

  1. Open Server Manager -> File and Storage Services -> Shares.
  2. Tasks -> New Share... and pick the SMB Share - Quick profile.
  3. Choose the server and a volume/path (e.g. D:\Shares\Finance).
  4. Name the share (e.g. Finance). Note the UNC path it shows.
  5. On Permissions, click Customize permissions to set Share and NTFS ACLs.
  6. Finish. The folder is now reachable at \\SERVER01\Finance.

You can also use the classic Computer Management -> Shared Folders -> Shares snap-in.

PowerShell

# Create the folder, then share it
New-Item -Path 'D:\Shares\Finance' -ItemType Directory

New-SmbShare -Name 'Finance' -Path 'D:\Shares\Finance' `
    -FullAccess 'CORP\Domain Admins' `
    -ChangeAccess 'CORP\Finance-RW' `
    -ReadAccess 'CORP\Finance-RO'

# Inspect and adjust
Get-SmbShare -Name Finance
Get-SmbShareAccess -Name Finance
Grant-SmbShareAccess -Name Finance -AccountName 'CORP\Auditors' -AccessRight Read -Force

The -FullAccess, -ChangeAccess, and -ReadAccess parameters set the Share permissions only - NTFS is separate (see below).

Share permissions vs NTFS permissions

This is the concept that trips up most admins. A shared folder is protected by two independent access-control layers, and the most restrictive of the two wins (the effective permission is the intersection).

Share permissions NTFS permissions
Applies to Access over the network (SMB) only Access always - network and local
Granularity Coarse: Full Control / Change / Read Fine: 14 special rights, per file/folder
Stored on The share object The filesystem (the volume must be NTFS)
Inheritance None Yes - flows down the folder tree 
Effective access = the MORE RESTRICTIVE of (Share permission, NTFS permission)

  Share = Change (Read/Write)        NTFS = Read
  ---------------------------------------------------
  Effective over the network        = Read   (NTFS wins, it is tighter)

The common pattern

Set Share permissions to a broad allow - typically Authenticated Users = Full Control (or Change) - and then do all real access control with NTFS permissions. NTFS is finer-grained and also protects local/RDP access, so it is the right place to be precise. Tightening the share layer too creates confusing "why can't they write?" puzzles.

NTFS basics: ACLs, inheritance, rights

NTFS access is defined by an ACL (Access Control List) made of ACEs (Access Control Entries) - one per principal (user or group), each Allow or Deny.

Standard rights roll up the granular ones:

Right Lets a user...
Read List, open, and read files and attributes
Read & Execute Read plus run executables
Write Create files/folders and write data
Modify Read + Write + delete the item
Full Control Modify + change permissions + take ownership

Inheritance: by default child files and folders inherit the ACL of their parent. Permissions set higher up flow down automatically; you can break inheritance on a subfolder to manage it independently.

Deny beats Allow

An explicit Deny ACE overrides any Allow (with one exception: an inherited Deny is overridden by an explicit Allow on the same object). Use Deny sparingly - it makes effective permissions hard to reason about. Prefer simply not granting access.

Viewing and setting NTFS permissions

GUI: right-click the folder -> Properties -> Security -> Edit (and Advanced for inheritance, ownership, and effective-access checks).

Command line with icacls:

# View the ACL
icacls D:\Shares\Finance

# Grant Finance-RW Modify, inherited by files and subfolders
icacls D:\Shares\Finance /grant 'CORP\Finance-RW:(OI)(CI)M'

# Grant read-only
icacls D:\Shares\Finance /grant 'CORP\Finance-RO:(OI)(CI)RX'

# Remove a principal
icacls D:\Shares\Finance /remove 'CORP\Auditors'

# Reset children back to inherited permissions
icacls D:\Shares\Finance /reset /T

# Back up / restore an ACL
icacls D:\Shares\Finance /save acl.txt /T
icacls D:\Shares /restore acl.txt

(OI) = object inherit (files), (CI) = container inherit (subfolders). The PowerShell equivalents are Get-Acl and Set-Acl, though icacls is usually faster for bulk changes.

Mapping a drive

Per session with net use

# Map Z: to the share
net use Z: \\SERVER01\Finance /persistent:yes

# With explicit credentials
net use Z: \\SERVER01\Finance /user:CORP\jdoe

# Remove the mapping
net use Z: /delete

The PowerShell-native option is New-PSDrive -Name Z -PSProvider FileSystem -Root \\SERVER01\Finance -Persist.

Centrally with Group Policy (preferred at scale)

Use Group Policy Preferences -> User Configuration -> Preferences -> Windows Settings -> Drive Maps. Create the mapping there, target it with item-level targeting (e.g. by security group), and every user in scope gets the drive automatically - no logon scripts. See Group Policy.

DFS: namespaces and replication

For anything beyond a couple of shares, DFS (Distributed File System) is worth knowing:

  • DFS Namespaces (DFS-N) present many shares across many servers under one logical path, e.g. \\corp.example.com\files\Finance. Users get a single, stable UNC even if the underlying server changes - great for migrations.
  • DFS Replication (DFS-R) keeps copies of folders in sync across servers (multi-site availability, branch offices).

DFS is an add-on role (DFS Namespaces / DFS Replication under File and Storage Services). It complements - it does not replace - Share and NTFS permissions, which still apply on the target folders.

Best practices

  • Do all granular control with NTFS; keep Share permissions broad. Remember the effective permission is the most restrictive of the two.
  • Assign permissions to groups, never individual users. Add/remove people by group membership - it scales and is auditable (see Active Directory groups).
  • Use the AGDLP model: put Accounts into Global groups, those into Domain Local groups, and grant the Permission to the domain local group.
  • Avoid Deny ACEs; prefer withholding access. Avoid breaking inheritance unless you have a clear reason.
  • Disable SMB 1.0; require SMB signing/encryption for sensitive shares (Set-SmbShare -EncryptData $true).
  • Use a hidden share (name$) for admin-only shares you do not want browsed.

Verify your work

  1. From a client, open \\SERVER01\Finance in Explorer and confirm you can reach it (and that you cannot reach a $ hidden share by browsing).
  2. Run Get-SmbShareAccess -Name Finance and confirm the Share ACL is what you set.
  3. Run icacls D:\Shares\Finance and confirm the NTFS ACEs and the (OI)(CI) inheritance flags are present.
  4. Test the "most restrictive wins" rule: set Share = Read for a test user who has NTFS Modify, then confirm they cannot write over the network but can write when logged on locally.
  5. Map the drive with net use Z: \\SERVER01\Finance and confirm Z: appears.

Summary

  • File sharing uses SMB; clients connect via UNC paths like \\SERVER01\Finance.
  • Create shares in Server Manager or with New-SmbShare.
  • Share permissions (network-only, coarse) and NTFS permissions (always, fine-grained) are independent - the effective access is the most restrictive of the two.
  • NTFS uses ACLs with inheritance; manage them via the Security tab or icacls. Deny beats Allow; use Deny sparingly.
  • Map drives with net use/New-PSDrive, or centrally with GPO Drive Maps; use DFS for unified namespaces and replication.
  • Best practice: keep Share broad, control with NTFS, assign to groups not users. See also PowerShell basics and Group Policy.

Test yourself