Access Denied does not tell you which permission layer failed.

01

Path

Use the exact UNC path. If the server or share cannot be reached, stop. You are still in DNS, routing, VPN, server, or SMB availability troubleshooting.

02

Identity

Confirm which Windows or domain account is actually being used. Saved credentials, alternate domain accounts, stale sessions, and local credentials can make the correct path fail under the wrong identity.

03

Share

Check the SMB share permission that applies when the user reaches the folder over the network. Treat it as one gate, not the whole answer.

04

NTFS

Check the file-system ACL on the actual folder or file, including group-based entries, inheritance, explicit permissions, and any Deny entries.

05

Effective access

Prove what the user actually receives from direct, inherited, and group-based permissions instead of assuming the visible ACL explains the result.

06

Verify

Test the action the user needs over the same network path: browse, open, create, edit, rename, or delete. The permission dialog is not the final test.

Share permission

The network doorway

Share permissions apply when the resource is reached through the SMB share. They can allow or restrict Read, Change, or Full Control at the share boundary.

NTFS permission

The file-system boundary

NTFS permissions apply to folders and files themselves. They control detailed rights and inheritance regardless of how complex the share structure becomes.

Network result

Both gates matter

For network access, the effective result cannot be more permissive than either layer allows. A permissive share does not override restrictive NTFS, and permissive NTFS does not override a restrictive share.

Local result

A local server test can differ

If the same user or admin can work with the folder locally on the server but network access fails through the UNC path, the share layer becomes an important comparison point.

Path not found

Do not start with ACLs

If the server name, share name, or route cannot be reached, solve connectivity or resource availability first. Permissions cannot fix a path that does not exist from the client.

Access Denied

Authorization is now plausible

Once the path resolves and the SMB service responds, verify identity, role-based groups, share permissions, NTFS permissions, and effective access.

Read works, write fails

Compare required rights

The user may have enough permission to list or open content but not enough for create, save, rename, or delete operations. Test the exact action the role requires.

One folder fails

Inspect the boundary

If sibling folders work but one child folder fails, look for broken inheritance, unique ACLs, different groups, or explicit entries at that folder boundary.

Role group

Use the intended access path

Compare the user with a known-good peer and identify the security group that should grant the role. Avoid solving ordinary access with privileged groups or direct Full Control.

Token

Refresh new membership

A newly added security-group membership may not be present in the user's existing Windows logon token. Sign-out, reconnect, or another approved token refresh may be required before retesting.

Nested groups

Follow the actual chain

Nested security groups can be valid but harder to reason about. If the permission path is not obvious, document the chain instead of adding another direct entry.

Effective Access

Prove the resulting rights

Use Windows Effective Access or an approved equivalent to verify the user's resulting permission at the exact object before changing the ACL again.

Avoid

Giving Full Control at both layers

That may make the symptom disappear while destroying least privilege and hiding which layer was actually wrong.

Avoid

Changing share and NTFS together

If you change both at once, you lose the comparison that would have identified the failing layer. Change the smallest justified thing after the failure is proven.

Avoid

Breaking inheritance as a first test

Unique permissions can be necessary, but they should not be a discovery tool. Preserve the existing ACL and a known-good access path before changing inheritance.

Avoid

Using Deny to force a quick result

Explicit Deny can interact with nested groups and other access paths in ways that are harder to troubleshoot later. Prefer a clean allow-based design unless the environment requires otherwise.

Same path

Working peer succeeds

If a peer with the same role can use the exact UNC path from a comparable device, the server and share are probably available. Compare identity, groups, token state, and effective access.

Same user

Local test works, UNC fails

That difference points toward the network-share layer or a different authentication context. Do not rewrite the NTFS ACL until the comparison is explained.

Same user

Parent works, child fails

That difference points toward inheritance or a unique ACL boundary on the child object.

Several users

The same share fails together

Move upstream. A shared failure can indicate the share itself, SMB service, server state, storage, identity dependency, or a broad permission change.

Escalate

The data owner or intended access is unknown

Do not infer business authorization from whatever ACL exists today. Get the approved role and owner clarified first.

Escalate

Inheritance or nested groups are complex

If multiple child folders, service accounts, applications, or nested groups depend on the same tree, document the current model before changing it.

Escalate

The change can affect production services

Backup, scanning, application, service, or automation identities may depend on the path. Preserve those dependencies before restricting access.

Mapped drive or UNC path confusion

Identify the real resource before rebuilding mappings or changing permissions. Troubleshoot mapped drives and file access →

Group membership just changed

Refresh the user's token and prove effective access before adding another ACL entry. Test access after a group change →

Inheritance must change

Preserve the approved access path and rollback record before restricting a child folder. Restrict inherited permissions safely →

Case proof: NTFS inheritance was the controlling layer

See how one public-safe case preserved approved access, converted inherited entries, removed only the unwanted broad ACE, and verified both sides without changing the SMB share. Read case KT-000005 →

You need a cleaner comparison

Hold one variable steady and compare against a working peer or path. Use a known-good comparison →