“Access Is Denied” Mapping a Drive Over SMB

Introduction

Someone maps a drive to a file server they have used for months, or tries a share for the first time after being added to the right group, and gets nothing but Access is denied. Their password is correct. Their account isn’t locked. Direct RDP to the server works fine. The share itself is visible in the browse list, sometimes, which somehow makes it worse — the server clearly knows the share exists, it just won’t let this particular connection in.

SMB access denials are frustrating precisely because “access denied” is the output of several unrelated checks that all produce the identical message. Share permissions, NTFS permissions, the authentication method negotiated, SMB signing requirements, and — for local accounts specifically — a UAC restriction on remote connections can each independently refuse the request. The fix is rarely mysterious once you know which gate closed; the time gets lost checking the wrong one first.

What You’re Seeing

The exact wording depends on how the connection was attempted, but it clusters into a small set of variants:

# net use / mapped drive - command line
System error 5 has occurred.
Access is denied.

# File Explorer - "Map network drive" or double-clicking a UNC path
Access is denied.
You do not have permission to access \\fileserver01\finance.

# Modern Windows clients connecting to a NAS or third-party SMB server
You can't access this shared folder because your organization's
security policies block unauthenticated guest access.

# Network capture (Wireshark/Netmon), filtered on SMB2
SMB2 Session Setup Response, Error: STATUS_ACCESS_DENIED (0xC0000022)

A related but distinct error is worth ruling out early because it is easy to mistake for a permissions problem: System error 1219, “Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed.” That is not an access-denied failure at all — it means an existing SMB session to that server is already open under a different credential, and Windows refuses to hold two identities against the same server at once.

What It Actually Means

Every SMB connection to a shared folder has to pass through two separate permission layers before the user’s request even reaches the file system: share permissions (set on the share itself, in the Advanced Sharing dialog or via Grant-SmbShareAccess) and NTFS permissions (set on the underlying folder’s Security tab, or via icacls/Get-Acl). These are evaluated independently, and the connecting user’s effective access is whichever of the two is more restrictive. A share permission of Full Control does nothing to widen an NTFS ACL that only grants Read, and vice versa — a common misconfiguration is assuming that opening up one side is enough.

Beyond the permission tables, the connection also has to satisfy whatever authentication and transport requirements the server enforces. Starting with Windows 11 24H2 and Windows Server 2025, unauthenticated guest sign-in is blocked by default, SMB signing is required in both directions, and SMB client-side NTLM blocking is available — any of which turns a connection that worked for years into an outright refusal the moment a client or server is upgraded, with no configuration change on the share itself. Separately, a local administrator account (a Security Account Manager account on the target machine, not a domain account) that connects remotely gets a filtered access token by default under User Account Control — it authenticates successfully but is denied administrative actions, including in some cases the connection itself, unless the remote UAC restriction has been explicitly disabled on the target.

How to Diagnose

Start from the client, cheapest checks first, before touching anything on the server:

# 1. Confirm exactly what's currently mapped/connected, and the literal error
net use

# 2. Check the negotiated SMB dialect and session state for the target server
Get-SmbConnection -ServerName fileserver01

# 3. Check the client's own security posture - signing, guest fallback, NTLM
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature, EnableInsecureGuestLogons

# 4. On the file server: confirm the share exists and check its ACL
Get-SmbShare -Name finance
Get-SmbShareAccess -Name finance

# 5. On the file server: check the NTFS ACL on the underlying folder
Get-Acl -Path "D:\Shares\Finance" | Format-List

# 6. Confirm which Kerberos tickets the client session actually holds
klist tickets

If none of that shows an obvious mismatch, check Event Viewer on the client under Applications and Services Logs → Microsoft → Windows → SMBClient, specifically the Connectivity and Security channels. Event ID 31017 specifically flags a connection refused because the server offered only guest authentication and the client’s policy blocks it — worth checking before assuming a permissions problem.

Common Causes

Working Through a Fix

Work the permission layers first, since they account for most cases and are the safest to check without touching client-wide security policy. Pull both ACLs side by side before changing anything:

# On the file server - see both permission layers at once
Get-SmbShareAccess -Name finance | Format-Table AccountName, AccessRight
Get-Acl -Path "D:\Shares\Finance" | Select-Object -ExpandProperty Access |
    Format-Table IdentityReference, FileSystemRights, AccessControlType

Grant the narrower of the two whatever the user actually needs, matching the same right on both layers rather than opening one side wide and leaving the other tight — a Full Control share ACL paired with a Read-only NTFS ACL still leaves the user at Read:

# Grant Change on the share
Grant-SmbShareAccess -Name finance -AccountName "CORP\Finance-RW" -AccessRight Change -Force

# Grant the matching Modify right on the NTFS ACL, applied to this
# folder and inherited by subfolders/files ((OI)(CI))
icacls "D:\Shares\Finance" /grant "CORP\Finance-RW:(OI)(CI)M"

If the permission layers check out and the failure is instead the guest-access or signing behaviour introduced by newer Windows defaults, the fix lives on the server or NAS, not the share ACL. Confirm the client’s own posture first so you’re not chasing a client-side setting that was never the cause:

# Client: is guest fallback or signing the reason this connection is refused?
Get-SmbClientConfiguration | Select-Object EnableInsecureGuestLogons, RequireSecuritySignature

# Server: bring SMB signing in line with what the client requires
Set-SmbServerConfiguration -RequireSecuritySignature $true

How to Prevent It

Keep share and NTFS permissions aligned to the same groups rather than layering broad share access on top of narrow NTFS access (or the reverse) — the mismatch is the single most common cause here, and it’s invisible until someone actually hits it. Document which group maps to which access level for each share, since “who can read Finance” tends to be tribal knowledge that outlives whoever set it up.

Treat the newer secure-by-default behaviours — blocked guest access, required signing, NTLM restrictions — as things to test for deliberately after any client or server upgrade, rather than debugging them cold when a user reports a share that “just stopped working.” For the authentication layer underneath all of this, see the Kerberos authentication post; if the failure turns out to be about firewall reachability to the file server rather than permissions, check Windows Firewall rules for File and Printer Sharing next.

Quick Reference

Final Thoughts

“Access is denied” over SMB is rarely one thing. It’s the visible output of several independent checks — share permissions, NTFS permissions, authentication method, signing requirements, and remote UAC filtering for local accounts — any one of which can refuse the connection on its own.

Work from the client outward: confirm what’s actually being negotiated with net use and Get-SmbConnection, then check both permission layers together rather than one at a time, and only then look at the newer secure-by-default behaviours if the account and folder configuration both check out.

For the mechanics behind that combination rule — why the more restrictive of the two permission layers always wins, and how to configure both from the GUI and PowerShell — see SMB File Shares — Share vs NTFS Permissions.