Windows Share Permissions vs. NTFS Permissions (The Intersection Trap)

Why 'Everyone: Full Control' on an SMB share still yields 'Access Denied', how Share ACLs intersect with NTFS ACLs, and ICACLS remediation.

The Problem

You configure a Windows or Samba share (e.g. \\SERVER\Data) and grant Everyone: Full Control in the Share Permissions tab.

Yet when a user connects over the network and tries to save a new file or modify an existing document, Windows immediately blocks them with:

Access is Denied. You need permission to perform this action.

The Rule: Effective Permission = Share ACL ∩ NTFS ACL

Every shared folder on Windows has two completely independent security barriers:

1. Share Permissions (SMB Layer): Evaluated when traffic first enters the network protocol.

2. NTFS Permissions (Filesystem Layer): Evaluated by the disk driver when the file is read or written.

If your Share Permission is Full Control, but the NTFS folder permission on the local disk is Users: Read & Execute, the user has Read-Only access over the network.

Best Practice Architecture

1. Keep Share Permissions Broad: Set Share Permissions to Authenticated Users: Change / Read (or Everyone: Full Control on trusted LANs).

2. Manage Security on NTFS: Restrict all access, departments, and user groups exclusively through NTFS Directory Permissions.

Fixing NTFS Permissions with icacls

Grant the local or domain users Modify permissions with directory and container inheritance:

# Grant 'Authenticated Users' Modify access with inheritance
icacls "D:\Data" /grant "Authenticated Users":(OI)(CI)M /T

# Or grant a specific local group:
icacls "D:\Data" /grant "Users":(OI)(CI)M /T

*Key Flags Explained:*

• (OI): Object Inherit (files inside this folder inherit permissions).
• (CI): Container Inherit (subfolders inherit permissions).
• M: Modify rights (read, write, delete, execute).
• /T: Traverse recursively through all existing files and subdirectories.