Overview
An Access Denied message on a network shared folder usually means the network path is reachable but the signed-in identity or file/share permission does not allow the requested access.
Why this happens
Network shares can be controlled by share permissions, NTFS permissions, group membership, cached credentials, VPN/network location, and server availability.
Before you begin
- Record the exact UNC path.
- Confirm the user should have access.
- Record whether Read or Modify access is expected.
- Do not add Everyone or broad domain groups to fix the issue.
Click-by-click troubleshooting
Step 1: Confirm the exact shared-folder path
Action: In File Explorer, enter the approved UNC path such as \\server\share.
Why this matters: A shortcut may point to an old or different location.
What to look for: Confirm the path opens to the correct server/share before the access error occurs.
Expected result: You should verify the correct resource is being tested.
Step 2: Confirm network or VPN access
Action: If remote and Windows built-in VPN is used, open Settings > Network & internet > VPN and connect the approved profile. Then test whether the server name resolves using nslookup servername.
Why this matters: Access Denied is different from a network path that cannot be reached.
What to look for: Confirm the server resolves and the share is reachable.
Expected result: The network path should be available before permission is evaluated.
Step 3: Verify the signed-in Windows identity
Action: Open Command Prompt and run whoami.
Why this matters: Windows may be using an unexpected local, domain, or work account.
What to look for: Confirm the displayed identity matches the account that should have access.
Expected result: The correct organizational identity should be in use.
Step 4: Compare another authorized user
Action: If available, confirm whether another approved user can access the same folder from a similar network path.
Why this matters: This distinguishes server/share problems from one user's permissions.
What to look for: Compare access results without changing permissions.
Expected result: If another user works, the problem is likely identity or group membership.
Step 5: Review expected group membership if authorized
Action: Use the organization's approved directory or access-management tool to confirm whether the user belongs to the intended access group.
Why this matters: Group-based permissions are safer and more maintainable than direct ad hoc grants.
What to look for: Confirm the correct security group and recent membership changes.
Expected result: The user should have the approved group membership required for the share.
Step 6: Capture the exact access boundary
Action: Determine whether the user can open the share but not one subfolder, or cannot open the share at all.
Why this matters: Different folder levels may have different NTFS permissions.
What to look for: Record the exact folder where Access Denied first appears.
Expected result: IT should know which permission boundary to inspect.
What to look for
- Share reachable but denied: permission issue.
- Server name fails: DNS/network issue.
- Another user works: user/group issue.
- Only one subfolder denied: nested permission boundary.
When to stop
When to contact IT
Contact J3 Systems Group if the correct user remains denied, group membership appears correct, the access boundary is unclear, or permission inheritance may be involved. Include article code KB-15.009, UNC path, user identity, and exact denied folder.
Need help with this issue?
J3 Systems Group supports small businesses and nonprofits with Microsoft 365, Google Workspace, cybersecurity, devices, documentation, and day-to-day IT operations.
Contact J3 Systems GroupAuthoritative references
Vendor interfaces, licensing, and security guidance can change. Verify current platform behavior against the primary documentation below before making high-impact production changes.