Fix SMB Share Access Denied in Windows 11 and 10: Share and NTFS Permissions

Think of it as a building with a front-door badge reader and an office-door key. A user needs both. Giving them access at the Sharing tab but not the Security tab will still leave them staring at the digital equivalent of a locked office door.

This guide applies to Windows 11 and the still-deployed Windows 10 environments that use standard SMB file sharing. Note that Windows 10 reached end of support on October 14, 2025, so organizations should plan an upgrade rather than treating an access-control repair as a long-term security strategy.

Start with the symptom: is it truly a permissions problem?​

From the affected PC, open File Explorer and enter the share directly:

\\ComputerName\ShareName

Use the computer name rather than browsing through Network. Network discovery can be flaky; a direct UNC path is the grown-up way to ask SMB whether it has a problem.

A genuine permissions issue normally looks like one of these:

Quick walkthrough

• The share opens for an administrator or one colleague, but not the affected user.
• The user can see the shared PC or folder but receives Access denied on opening it.
• The user can open the share but cannot create, rename, edit, or delete files.
• Some subfolders work while others reject access.

If Windows instead says the network path cannot be found, asks endlessly for credentials, or cannot contact the host, tackle connectivity or authentication first. Microsoft’s SMB troubleshooting guidance distinguishes these connection-stage failures from authorization failures occurring after a user has connected.

The rule that explains most “Access denied” errors​

Windows checks permissions in two places:

• Share permissions — configured on the folder’s Sharing tab.
• NTFS permissions — configured on the folder’s Security tab.

For a person connecting through the network, the result is effectively the most restrictive combination of the two. A user with Change at the share level but only Read in NTFS can read, not edit. A user with Full Control on NTFS but no permission to use the share is stopped at the front gate.

Microsoft’s access-control documentation confirms that share permissions and file-system permissions are separate authorization layers. That separation is useful, but it can also make a five-minute folder share become a small bureaucratic opera.

Before changing permissions: identify the right account​

Do not add random accounts until something works. First establish the identity Windows is actually using.

On the client PC, open Command Prompt and run:

whoami

For a Microsoft-account sign-in, the local identity may not look like the email address a user expects. In a business domain, use the domain account or—better yet—a domain security group. For a home or workgroup network, the target PC may authenticate the user as a local account stored on the PC hosting the share.

For a local account on the host PC, use this format when prompted for credentials:

HOSTPC\UserName

For a domain account, use:

DOMAIN\UserName

Using the wrong identity is a remarkably efficient way to “fix” permissions for somebody who is not actually connecting.

Step 1: Confirm the folder is shared​

On the PC that hosts the files:

• Right-click the folder and select Properties.
• Open the Sharing tab.
• Select Advanced Sharing.
• Confirm Share this folder is checked.
• Note the Share name. This is the name users must enter after the computer name in the UNC path.
• Select Permissions.

For a controlled setup, remove overly broad entries that are not needed and add a specific user or security group. A sensible starting point is:

Avoid treating Everyone: Full Control as a permanent cure. Microsoft’s general troubleshooting article shows it as a broad diagnostic remedy, but it is not a least-privilege design. It can help prove that a permission block exists; it should not become the default access model for a sensitive folder.

A practical configuration pattern​

For a small business or home-office share, many administrators use:

• Share permissions: authenticated users or a relevant group receive Change.
• NTFS permissions: the real access rules live here, with separate Read and Modify groups as needed.

That keeps the share layer simple while preserving fine-grained control in NTFS. It also avoids rebuilding the same permission maze twice.

Step 2: Fix NTFS permissions on the Security tab​

Still on the host PC:

• Right-click the shared folder and select Properties.
• Open the Security tab.
• Select Edit, then Add.
• Enter the affected user or group name.
• Select Check Names to confirm Windows resolves it.
• Grant only the necessary rights:
• Read & execute for view-only access.
• Modify for normal collaboration.
• Full control only where administration is genuinely required.
• Select Apply, then OK.

For ordinary shared working folders, Modify is usually the right collaboration permission. It allows users to create, edit, rename, and delete files without handing them the keys to rewrite the folder’s permissions.

Why Read may not be enough​

A user may appear to have access because they can open the folder, yet fail when saving a document. That usually means the account has read access but lacks the required write, create-file, rename, or delete rights. “It opens” and “it is usable” are not the same test.

Step 3: Check inheritance before rebuilding everything​

If a subfolder fails while the parent folder works, inspect inheritance.

• Open the problem folder’s Properties.
• Select Security > Advanced.
• Look for entries marked as inherited.
• Check whether inheritance is enabled.

Windows normally passes eligible permissions from a parent folder to its child folders and files. Microsoft’s access-control guidance describes inheritance as the mechanism that lets objects within a folder receive inheritable permissions from that folder.

Problems appear when someone has:

• Disabled inheritance on a child folder.
• Converted inherited entries into explicit rules and later edited them.
• Added an explicit Deny permission.
• Copied files or folders from another location carrying unusual ACLs.

An explicit deny entry can override an allow entry for the same right. Treat Deny permissions like a fire alarm behind glass: use them only when you have a very specific reason and understand whom they affect.

If the child folder should behave like its parent, enable inheritance from the Advanced Security Settings window. Review the proposed permissions before applying changes, especially on folders containing confidential files.

Step 4: Check the effective permissions, not just the visible list​

Permission lists can be deceptive because a person may receive access through multiple groups. The Advanced security settings can show the effective access for a selected account.

Use this to answer the question that matters: What can this actual user do on this actual folder?

Check the user’s rights on:

• The shared root folder.
• The specific subfolder that fails.
• A representative file, if opening works but editing fails.

A missing permission on one nested folder can produce an “Access denied” error that makes the whole share look broken. In reality, one rogue ACL may be the entire story.

Step 5: Clear stale or incorrect saved credentials​

Windows may quietly reuse credentials saved for the remote computer. If another user previously accessed the host from the same PC, Windows can attempt the wrong account automatically.

On the affected PC:

• Search for and open Credential Manager.
• Select Windows Credentials.
• Look for entries matching the host computer name, its fully qualified name, or IP address.
• Remove only the relevant saved credential.
• Disconnect and reconnect to the share.
• When prompted, enter the intended account in HOSTPC\UserName or DOMAIN\UserName form.

Microsoft’s Credential Manager documentation confirms that Windows credentials include saved sign-in information for network resources.

For a more deterministic test, open Command Prompt and remove existing connections to the share:

net use \\ComputerName\ShareName /delete

Then create a fresh authenticated connection:

net use \\ComputerName\ShareName /user:HOSTPC\UserName *

The asterisk prompts for the password rather than putting it into the command history. That is not merely tidier—it is much less likely to turn your password into office archaeology.

If Windows reports that multiple connections to the same server using different credentials are not allowed, disconnect existing sessions to that host first. Windows generally expects one credential context per server name within a session.

Step 6: Test from another PC the right way​

A good test separates authentication from permissions.

From a second PC:

• Sign in as the affected person, if possible.
• Open:
  \\ComputerName\ShareName
• Test the action they need:
• Open a file.
• Create a temporary folder.
• Create and save a test document.
• Rename it.
• Delete it.

Then remove the test items.

Do not test solely as an administrator. Administrators often have elevated rights that conceal the very permissions issue a standard user will encounter. The account that fails is the account that needs testing.

If the Security tab is missing​

The Security tab depends on the folder being stored on an NTFS-formatted volume. If the drive is FAT32 or exFAT, NTFS ACLs are unavailable, so you cannot configure the same per-user Security permissions.

Check the drive’s file system by right-clicking the drive in File Explorer, selecting Properties, and looking at File system.

For a shared folder requiring separate access rules for different people, use an NTFS volume. Copying the data to NTFS may be safer than attempting an in-place conversion without a verified backup.

Do not “solve” this by weakening SMB security​

A permissions error is not a reason to enable SMBv1, turn on guest access indiscriminately, or disable newer SMB protections. Microsoft’s current SMB guidance says SMBv1 is not installed by default and recommends keeping it disabled. Modern Windows versions also continue to harden SMB authentication and signing behavior.

If a legacy NAS or appliance only works after enabling insecure guest access or SMBv1, that is a compatibility problem with the device—not a normal fix for a Windows permissions configuration. Upgrade the device firmware, configure named accounts, or replace hardware that cannot support a modern SMB setup.

A fast diagnosis checklist​

Before escalating the problem, verify all of the following:

• The folder is actually shared and the UNC path is correct.
• The user is connecting with the intended local or domain account.
• The Share permissions allow the required action.
• The NTFS Security permissions allow the required action.
• There is no explicit Deny entry blocking the account or one of its groups.
• The affected subfolder still inherits the intended permissions.
• Cached Windows credentials for the host have been removed or corrected.
• The test was performed from another PC using the affected user’s identity.
• SMBv1 and anonymous guest access were not enabled as a shortcut.

The reliable fix: make the two permission layers agree​

The cleanest resolution is rarely “give Everyone Full Control.” It is to identify the affected account, assign the smallest practical permission at both the share and NTFS layers, verify inheritance on problem subfolders, and test a real file operation from another PC.

Once you approach network share access as a two-lock system—share access plus NTFS access—the mystery largely evaporates. Windows is not being whimsical. It is simply enforcing exactly what it was told, with all the literal-minded enthusiasm of a bouncer who has read the policy manual twice.