Error 0x80070005 — Access Is Denied on a Network Share (Fix)

What This Error Means

\HOSTNAME\ShareName is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions. Error code: 0x80070005 Access is denied.

Unlike most SMB errors, 0x80070005 means Windows reached the machine, reached the share, and went through the authentication process — then was rejected at the permission layer. The connection works; your account does not have access.

This has three distinct causes at three different permission layers.

Understanding the Two-Layer Permission System

Windows shared folder access is controlled by two independent permission sets, both of which must grant access:

1. Share permissions — who can access the share at all (configured via the Sharing tab)
2. NTFS permissions — who can read/write the underlying folder on disk (configured via the Security tab)

Both must grant access. If a user has Full Control in share permissions but is denied by NTFS permissions (or vice versa), they are denied. 0x80070005 can come from either layer.

Root Cause 1 — Wrong Credentials (No Matching Account)

Most common cause. When password-protected sharing is enabled, Windows matches the connecting user's account credentials against local accounts on the host machine. If no matching account exists, the connection is denied.

Symptoms: The error appears when connecting; you are never asked for credentials (or credentials are rejected if entered).

Fix:

1. On the host machine: Settings → Accounts → Other users → Add someone else to this PC → add the connecting user's account name and password
2. On the client machine: Control Panel → Credential Manager → Windows Credentials → remove any outdated entries for the host machine → browse to the share → enter the new credentials when prompted

Alternatively: Create one generic access account on the host (e.g., teamaccess) and share the credentials with all staff who need access.

Root Cause 2 — Share Permissions Restricting Access

The share itself may have permissions that exclude the connecting user.

Fix: On the host machine:

1. Right-click the shared folder → Properties → Sharing tab → Advanced Sharing → Permissions
2. Check who is listed and what permissions they have
3. To allow everyone on your private network: add "Everyone" → Full Control
4. To restrict to specific users: add only those user accounts → appropriate permission level
5. Click OK → Apply

Root Cause 3 — NTFS Permissions Restricting Access (Most Overlooked)

Even if share permissions grant access, NTFS permissions on the underlying folder override them. Many administrators fix the share permissions and miss this.

Fix: On the host machine:

1. Right-click the shared folder → Properties → Security tab (not Sharing)
2. Check who is listed in the "Group or user names" section
3. If the connecting account (or "Everyone" or "Authenticated Users") is not listed — or is listed with "Deny" — that is the problem
4. Click Edit → Add the appropriate account → grant Read or Full Control
5. Click OK → Apply

Important: "Deny" entries override "Allow" entries. If a user appears in both Allow and Deny, Deny wins. Remove Deny entries for accounts that should have access.

Root Cause 4 — User Account Inheriting a Deny Entry

Deny entries can be inherited from parent folders. If the folder's parent directory has a Deny entry for the connecting user or a group they belong to, the child folder inherits it.

Check: Security tab → Advanced → look for "(inherited)" deny entries. To override: either change the permission at the parent level or click Disable inheritance on the child folder and explicitly set the permissions you need.

Root Cause 5 — Trying to Connect as a Local Administrator Account That Has Been Filtered

Windows UAC (User Account Control) filters tokens for network access from administrator accounts. If you are connecting as a local administrator account (not a domain admin), the connection may receive a filtered (limited) token that lacks certain access rights.

Fix:

1. Create a non-administrator local account for network access
2. Use that account's credentials for the network connection

Or, for advanced users, enable LocalAccountTokenFilterPolicy:

# Caution: this affects security policy
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -Name "LocalAccountTokenFilterPolicy" -Value 1

Only apply this on isolated private networks with strong physical security.

Diagnostic Decision Tree

Can you access the share at all? (Even a read-only view)
├── YES → Share permissions OK → Check NTFS permissions (Security tab)
└── NO → Are you prompted for credentials?
    ├── NO → Share permissions block anonymous → Fix share permissions or add credentials
    └── YES → Credentials rejected → Create matching local account on host

---

Done troubleshooting Windows?

Oxolan uses its own access control — no Windows permissions required.

Get Oxolan for Windows

---

Frequently Asked Questions

Error appears for one user but not others connecting to the same share. Why? That user's account either has no matching local account on the host, has a stale credential in Credential Manager, or is the subject of a specific Deny entry in NTFS permissions. Check all three.

I can see files in the share but cannot edit or save them. Is this 0x80070005? Yes — the read permission is granted but write permission is not. Check NTFS permissions on the Security tab for the user's account and ensure Write or Full Control is granted.

Error appears after moving a shared folder to a different drive. Why? Moving a folder to a different drive severs the NTFS permission inheritance from the original parent. The folder's own stored permissions may be different from what was inherited, resulting in 0x80070005 for accounts that previously worked.

Can I script the NTFS fix instead of clicking through the Security tab? Yes:

$acl = Get-Acl "D:\SharedFolder"
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("HOSTNAME\USERNAME","FullControl","ContainerInherit,ObjectInherit","None","Allow")
$acl.SetAccessRule($rule)
Set-Acl "D:\SharedFolder" $acl

Replace HOSTNAME\USERNAME with the appropriate account.