Articles

Storage and shares on Windows Server: volumes, SMB and permissions

SMB shares and NTFS permissions: how a disk becomes a volume and who can reach it.

Reading: 6 minServer & Virtualization

Article cover: Storage and shares on Windows Server: volumes, SMB and permissions

Storage on Windows Server is two problems stacked. The first is making a disk usable: initialise it, partition it, format a volume. The second is making a folder reachable by other machines: share it over SMB and decide who may use it. Those two permission systems — share permissions and NTFS permissions — combine, and misunderstanding how they combine is the usual reason a user who should have access does not.

The model: a disk becomes a volume, a folder becomes a share

A new disk appears to Windows as RAW and unusable until it is initialised, which writes a partition style. Initialize-Disk sets that style and defaults to GPT; MBR is the alternative. MBR is the older scheme: it supports up to four primary partitions and is limited to disks of 2 TB or smaller, while GPT supports larger drives and more partitions. Initialising acts on a RAW disk, so a disk that already holds data has its partitions removed and is backed up first.

Initialize-Disk -Number 1 -PartitionStyle GPT
New-Partition -DiskNumber 1 -UseMaximumSize -DriveLetter T
Format-Volume -DriveLetter T -FileSystem NTFS -NewFileSystemLabel 'Data'

New-Partition creates a partition on a disk and Format-Volume turns it into a formatted volume with a file system — the command-line equivalents of Disk Management’s initialise, New Simple Volume and format steps. When several disks must act as one resilient unit, Storage Spaces aggregates physical drives into a storage pool and carves virtual disks from it, each with its own resiliency type: simple (striped, no redundancy), mirror (data duplicated two or three times) or parity.

Formatting: NTFS or ReFS

NTFS is the default and the file system to assume unless there is a reason not to. ReFS is a newer system built to maximise data availability and integrity across large data sets: it uses checksums for metadata and optionally for file data, and when it runs on a mirror or parity space it can repair detected corruption automatically from the other copy, with a scrubber that scans the volume and triggers repairs. ReFS is chosen for that integrity and scale; NTFS remains the general-purpose choice. The decision is made at format time with Format-Volume -FileSystem.

SMB shares

A share is a folder the server exposes to remote clients over SMB, the Server Message Block protocol. New-SmbShare creates one and, in the same command, grants rights: -FullAccess, -ChangeAccess, -ReadAccess and -NoAccess name the accounts, and -EncryptData turns on SMB encryption for the share.

New-SmbShare -Name 'VMSFiles' -Path 'D:\Public' -ChangeAccess 'CONTOSO\Finance Users' -FullAccess 'Administrators' -EncryptData $true
Get-SmbShare
Get-SmbShareAccess -Name 'VMSFiles'

Get-SmbShare lists the shares a computer is displaying — including the default administrative shares C$, ADMIN$ and IPC$ — and Get-SmbShareAccess reads back the share’s own ACL, showing each account and its access right of Full, Change or Read.

Share permissions and NTFS permissions

There are two permission layers, and they answer different questions. Share permissions apply only to access that arrives over the network through the share; they have three levels, Full, Change and Read, and they do not exist for a user sitting at the console. NTFS permissions are access-control entries on the file-system object itself, and they apply both locally and over the network, which is what makes them the finer-grained layer.

over the network   client ──▶ SMB share ──┐
                                          ├──▶ NTFS permissions ──▶ the file
at the console     sign-in ───────────────┘
                   (the share ACL is consulted only on the network path)

The two combine: to reach a file over a share, a user must be permitted by the share and by NTFS. Access allowed through NTFS can still be denied through share permissions. That asymmetry has a documented consequence in the other direction: the Effective Permissions tab of a file’s Advanced Security Settings shows what NTFS grants, but share permissions are deliberately not part of that calculation, so the tab is not a complete answer for a remote user. In practice the share is often left generous and the real control placed in NTFS, where the entries are inherited, granular and auditable.

Sessions, open files and verification

When a share misbehaves, the identity of the problem is usually a session or an open file. Get-SmbSession lists the SMB sessions currently established with clients — client computer, user and number of opens — and Get-SmbOpenFile lists the individual files open on behalf of those clients, with the path and the user holding each one. Together they turn “the file is locked” and “who is using this share” into a query rather than a guess.

Limits and the common errors

A share is not a security boundary on its own: the same folder is reachable at the console through its NTFS permissions regardless of the share ACL, so a folder whose only protection is a restrictive share is not protected from a local sign-in. The common error is granting access at the share and forgetting the NTFS entry — or the reverse — and then reading the Effective Permissions tab, which omits share permissions, as proof that access is correct. A second error is choosing a partition style or a file system by habit: MBR cannot present a drive larger than 2 TB, and ReFS is not a drop-in replacement on every volume. A third is treating a mapped drive letter as a durable setting; it is a per-session view of a share whose real address is the UNC path.

Level and prerequisites. L2 — operational: initialise, partition and format a volume, create an SMB share, and read both permission layers. The physical layer below this — controllers, arrays and the storage fabric — is out of scope here.

Where to go next

References