{"id":281,"date":"2026-01-14T02:00:09","date_gmt":"2026-01-14T02:00:09","guid":{"rendered":"https:\/\/windows-vps.org\/blog\/?p=281"},"modified":"2026-08-18T22:23:17","modified_gmt":"2026-08-18T22:23:17","slug":"how-to-connect-to-vps-windows-10-a-complete-step-by-step-tutorial","status":"publish","type":"post","link":"https:\/\/windows-vps.org\/blog\/how-to-connect-to-vps-windows-10-a-complete-step-by-step-tutorial\/","title":{"rendered":"NTFS vs Share Permissions on Windows Server: Which One Really Controls Your Web Files"},"content":{"rendered":"

Every Windows administrator eventually hits the wall where “I granted Full Control but the app still cannot read the file” or “the share works but the website 403s.” The usual cause is a misunderstanding of the two independent permission layers on a Windows Server: share permissions<\/strong> applied at the SMB layer, and NTFS ACLs<\/strong> stored on the volume. They are not interchangeable, and the effective permission is always the most restrictive combination of both.<\/p>\n

Where each layer lives<\/h2>\n

Share permissions are evaluated only when a client connects through a network share such as \\\\server\\data<\/code>. They are stored with the share definition, not with the files. NTFS permissions live in the access control list on the volume itself, which means they apply to every<\/em> path of access: RDP logons, local service accounts, IIS application pools, scheduled tasks, and SMB connections alike.<\/p>\n

Because the two layers are evaluated in sequence, a client must pass both. The effective permission is the intersection:<\/p>\n

Share permission<\/th>NTFS permission<\/th>Effective permission<\/th><\/tr><\/thead>
Everyone: Full Control<\/td>Users: Read<\/td>Read<\/td><\/tr>
Everyone: Full Control<\/td>Users: Modify<\/td>Modify<\/td><\/tr>
Everyone: Read<\/td>Users: Full Control<\/td>Read<\/td><\/tr>
Everyone: Full Control<\/td>Users: Full Control<\/td>Full Control<\/td><\/tr><\/tbody><\/table><\/figure>\n

Which layer should carry your rules?<\/h2>\n

For a web server or any single-purpose box, the rule of thumb is: set the share to Everyone (or Authenticated Users) Full Control and do all real access control in NTFS<\/strong>. Three reasons. First, NTFS ACLs follow the files no matter how they are accessed, so a change applies to IIS, RDP users and SMB clients consistently. Second, NTFS supports inheritance, granular rights (read, write, execute, delete subfolders) and per-user ACEs; share permissions offer only Read\/Change\/Full Control. Third, NTFS is where tools like icacls<\/code> and the Effective Access tab already look, so troubleshooting stays in one place.<\/p>\n

Share permissions matter in the opposite scenario: when the volume is FAT or exFAT (no NTFS ACLs exist), when you want to hide a folder from everyone except a specific group at the SMB layer, or when you are sharing a NAS volume where the underlying file system ACLs are managed elsewhere.<\/p>\n

Worked example: an IIS site folder<\/h2>\n

Take a site at D:\\wwwroot\\contoso<\/code> served by app pool identity IIS APPPOOL\\contoso<\/code>. Create the share with full share-level access, then restrict at the NTFS layer:<\/p>\n

New-SmbShare -Name "contoso-www" -Path "D:\\wwwroot\\contoso" -FullAccess "Everyone"\n\nicacls "D:\\wwwroot\\contoso" \/grant "IIS APPPOOL\\contoso:(OI)(CI)(RX)"\nicacls "D:\\wwwroot\\contoso" \/grant "CONTOSO\\webadmins:(OI)(CI)(M)"\nicacls "D:\\wwwroot\\contoso" \/grant "CONTOSO\\uploaders:(OI)(CI)(WD,AD)"<\/code><\/pre>\n
The (OI)(CI)<\/code> flags make the ACE inherited by files and subfolders; (RX)<\/code> is read-and-execute, (M)<\/code> is modify, and (WD,AD)<\/code> is write-data plus append-data for an upload directory. Any client connecting through \\\\server\\contoso-www<\/code> still has to pass the NTFS ACL, so the permissive share grants nothing by itself.<\/p>\n
Verify with Effective Access, not guesswork<\/h2>\n
The Effective Access tab (right-click the folder, Properties → Security → Advanced → Effective Access<\/strong>) computes the real NTFS result for a user or group, including inherited ACEs and deny entries. It does not show the share layer, so combine it with a quick share check: Get-SmbShare<\/code> lists the shares and their permission sets, and icacls "D:\\wwwroot\\contoso"<\/code> dumps the raw ACLs.<\/p>\n
When a client reports access denied, work the layers in order: can they reach the share at all (net use<\/code>), does a share-level allow exist, does the NTFS ACL allow the action, and is a Deny ACE lurking at either layer? Nine times out of ten the answer is an inherited NTFS deny or a share set to Read that someone forgot about.<\/p>\n
Common traps<\/h2>\n