File Sharing and NTFS Permissions on Windows VPS

SMB on a Windows VPS is useful for deployments, log pickup, and a small team share. It is also port 445, which should never face 0.0.0.0/0 on a public IPv4. The permission model is two layers that both have to say yes: share permissions and NTFS ACLs. Everyone Full Control on the share plus a sloppy NTFS ACL is how a contractor writes into C:\inetpub. Change=Read on the share plus a perfect NTFS ACL is how deployments fail with Access Denied and people "fix" it by opening everything.

Get the network scope right first. Then create a dedicated share user or group, grant the minimum share permission, and put the real control on NTFS with icacls. Inheritance is your friend until you break it in a subdirectory and spend an afternoon wondering why one folder disagrees.

Scope 445 before you create the share

File and Printer Sharing rules are inbound TCP 445 (and legacy 139). Enable them only with a RemoteAddress of the office or jump host. If you do not have a static admin IP, do not share the folder over the internet. Use SFTP, a deploy pipeline, or RDP copy. L3/L4 DDoS filtering does not make an open SMB listener a good idea.

New-Item -ItemType Directory -Path 'D:\shares\deploy' -Force
New-LocalUser -Name 'deploy' -Password (Read-Host -AsSecureString 'deploy password') -PasswordNeverExpires
New-SmbShare -Name 'deploy' -Path 'D:\shares\deploy' -FullAccess 'Administrators' -ChangeAccess 'deploy'
Grant-SmbShareAccess -Name 'deploy' -AccountName 'deploy' -AccessRight Change -Force
Revoke-SmbShareAccess -Name 'deploy' -AccountName 'Everyone' -Force -ErrorAction SilentlyContinue
Get-SmbShare | Format-Table Name, Path, EncryptData
Get-SmbShareAccess -Name 'deploy'
Set-NetFirewallRule -DisplayGroup 'File and Printer Sharing' -Enabled True -RemoteAddress 203.0.113.10
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, EncryptData, RequireSecuritySignature
Set-SmbServerConfiguration -EnableSMB1Protocol $false -EncryptData $true -Force

Prefer a data volume for shares so IIS logs and Windows do not share fate with user files. If you only have C:, put shares under C:\shares, not under C:\Users\Administrator\Desktop. Turn SMB1 off. Encryption on the share is cheap on a LAN-sized admin prefix.

NTFS is where least privilege actually lives

Share permission Change plus NTFS Modify is the usual deploy combo: the deploy user can write files, cannot change share permissions, and cannot take ownership. Administrators keep Full Control on NTFS so you can still fix ACLs when a copied ZIP brings a broken DACL from a laptop.

icacls 'D:\shares\deploy' /inheritance:d
icacls 'D:\shares\deploy' /grant:r 'Administrators:(OI)(CI)F'
icacls 'D:\shares\deploy' /grant:r 'deploy:(OI)(CI)M'
icacls 'D:\shares\deploy' /remove 'Users'
icacls 'D:\shares\deploy' /remove 'Everyone'
icacls 'D:\shares\deploy'
Get-Acl 'D:\shares\deploy' | Format-List

OI and CI inherit to files and folders. /grant:r replaces that user's ACE instead of stacking duplicates. Removing Users and Everyone after disabling inheritance is the step people skip. Builtin Users often still has Read from the parent. That is fine for a public website directory; it is not fine for a deploy share that holds web.config and connection strings.

IIS site roots need a different DACL: IIS_IUSRS or the app-pool identity Read-and-execute, Administrators Full, deploy Modify if you publish over SMB. Do not give IIS_IUSRS Modify on the whole site unless the app must write. Put uploads in their own folder with write, keep code read-only.

How the two layers combine

Windows checks share permission first, then NTFS. The effective right is the more restrictive of the two. Full Control on the share and Read on NTFS is Read. Read on the share and Modify on NTFS is Read. Set the share to Change for the deploy user and do the interesting work in NTFS so you can vary folders without a second share.

Map the share from a workstation as \\VPS_IP\deploy with the deploy account, not with Administrator. Confirm a file write, confirm a file you should not delete is protected, then disconnect. If mapping fails, it is almost always firewall RemoteAddress, SMB1-only client, or a wrong password, not icacls.

Do not expose this share to customers. Do not use Guest. Do not put NTFS Full Control on Everyone because a vendor PDF said so in 2012. Audit successful write on the share folder if the data is more than static HTML.

Takeaway

Scope SMB to admin IPs, drop Everyone from the share, and put least privilege on NTFS with icacls. The effective right is the tighter of the two layers. Build the share on a Windows VPS at Netbay in Lucknow, keep 445 off the public internet, and map it from a prefix you control via netbayhosts.in.