0x80070005 access denied on a network share you are sure you can open

Fix it now

0x80070005 is Win32 5, “Access is denied”. On a share that is a refusal, not a failure to connect: the host was found, a session was made and a credential was accepted. Effective access is the narrower of the share and NTFS permissions, on top of a right to log on to that machine over the network at all.

net use
net use * /delete
Get-SmbShareAccess -Name Data
whoami /groups

1. Read net use first. It shows which credential each live session was made with, and Windows reuses an existing session to a server before it considers a new one.
2. On the server, compare the share permission from Get-SmbShareAccess with the folder’s own permissions. Effective access is the narrower of the two, and a share granting Read caps everything behind it at read.
3. Check the specific user, not the groups: folder Properties, Security, Advanced, Effective Access, and enter the account.
4. If the user was recently added to a group, sign them out and back in. Group membership is fixed into the logon token and does not update on its own; whoami /groups proves whether the new group is in the token.
5. On the server, confirm the account is not blocked from network logon in the local security policy, under User Rights Assignment.

Do not manage access in both places. Decide that the file system holds the real answer and keep the share permission broad enough not to interfere, or you will be debugging the intersection of two lists for the rest of the share’s life.

If the user can create and delete a file in the destination, stop here. If not, the next section works through the three layers in the order Windows evaluates them.

Why it happens

A share has its own permission list, which applies only to connections made over the network. The folder behind it has a file system permission list, which applies to everyone regardless of how they reach it. What a user can actually do is the intersection. This is the single most common reason for a refusal that makes no sense when you look at only one of the two, and it is why an administrator sitting at the server can do something the same account cannot do over the network.

Underneath both is a user right. An account must be permitted to access the computer from the network, and must not appear in the matching deny list, before either permission set is consulted at all. A share that stops working for one group after a policy change is usually explained there rather than in any access control list.

The companion codes tell you how far the request got, and two of them are worth reading carefully because their published meanings are narrower than the usual paraphrases. 0x80070041 is Win32 65, “Network access is denied”, a refusal at the network access layer specifically. 0xC0000022 is STATUS_ACCESS_DENIED: a process has requested access to an object but has not been granted those rights. 0x800704DC is Win32 1244: the operation was not performed because the user has not been authenticated – no valid credential was established, rather than one being rejected.

0x800704F1 is the one most often misread. Its symbolic name, ERROR_DOWNGRADE_DETECTED, suggests a security downgrade on the channel to the domain, and that is how it is usually described. Microsoft’s published text says something else: “The system cannot contact a domain controller to service the authentication request. Please try again later.” If you see it, check controller reachability before you go anywhere near the machine account.

Full reference

The five codes, with their published wording

0x800704DC and 0x800704F1 are the two that change where you look. The first says no credential was ever established, so stop reading access control lists and find out why authentication did not happen. The second, despite its name, says a domain controller could not be reached.

Where to look, by symptom

The order Windows actually evaluates things

1. Can this account log on to this computer over the network at all? The user right, and the matching deny right, decide that before anything else.
2. Has a credential been established? If not, you get 1244 rather than an access decision.
3. What does the share permission allow this token? That is the ceiling for everything behind it.
4. What does the file system permission allow this token? Explicit deny beats any allow, including inherited ones.
5. The result is the narrower of the last two, and it is what Effective Access shows you.

Working in that order saves time because each step rules out everything below it. Somebody who cannot log on over the network will never produce an interesting permissions answer, and somebody with a deny entry on the folder will not be helped by a broader share permission.

Commands that answer a specific question

Any registry change that relaxes remote administrative access, and any change to the network logon user rights, widens what an attacker can do with a single stolen local credential. Apply such a change to the one machine that needs it rather than through a policy across the estate, export the branch first, and record why it exists where the next rebuild will find it.

Every code this article covers

Confirm the fix worked

1. Have the affected user create and delete a file in the destination folder, as themselves.
2. Check Effective Access for that user shows the permission you intended.
3. Confirm net use shows the connection under the expected account.
4. Sign the user out and in again, then confirm access still works from a fresh session.
5. If a policy set the user right, force a refresh and retest rather than trusting the local setting.

Questions people ask about this