The folder is found, the password accepted — and Windows still says you do not have permission. Two separate locks guard every shared folder, and you have only been looking at one of them.
Access denied is the most honest error in this whole series: Windows reached the folder and the folder refused you. The refusal comes from a system with two locks in series — share permissions and NTFS permissions — where the stricter lock decides and a single Deny beats every Allow. Most failed attempts fix one lock, test, fail, and conclude permissions are 'broken'. They are not broken; they are layered. This page shows both layers, the three mistakes that account for nearly every case, and how to grant exactly the access needed — no more.
You do not have permission to access \\DESKTOP-PC\Share. Contact your network administrator to request access.
Compare the wording carefully with the path error. 'You do not have permission to access' means the network, the name, the sign-in all worked — you reached the folder's door authenticated, and the folder said no. This is the one sharing error that genuinely is about permissions, and it is fixed on the host PC, at the folder, not on your machine. Nothing you change on the PC that is reaching out can grant a permission the host has not given.
It also tells you something useful: the account you signed in with is known to the host. An unknown account usually fails earlier, at the credential stage. So the question now is narrow — what is this known account allowed to do?
Every network access passes two independent checks. The share permissions (folder Properties → Sharing → Advanced Sharing → Permissions) govern coming in through the network. The NTFS permissions (folder Properties → Security) govern the files themselves, for network and local users alike. Your effective permission is the more restrictive of the two: Read on the share and Full Control on NTFS still results in Read over the network, and a Deny anywhere outweighs every Allow.
This is why 'but I gave Everyone full control' so often changes nothing — the person set one lock and the other stayed shut. Check both, every time, in that order.
The account is not in the list at all. Permissions name accounts and groups, not 'people on the network'. If neither your account nor a group containing it (Users, Everyone, Administrators) appears in both tabs, you have no permission — silence in the list is a denial.
Everyone was added to the wrong tab. A very common tutorial adds Everyone on the Security tab but the share itself still lists only the owner. Or the reverse. Compare the two lists side by side; they should tell the same story.
An inherited Deny from above. Permissions flow down from parent folders. A Deny set on a parent — sometimes left by a backup tool, a security product or an old experiment — lands on your folder quietly and wins over your Allows. In the Security tab, use Advanced to see where each entry was inherited from before adding more entries on top of a contradiction.
On the host, open the folder's Properties. On the Sharing tab → Advanced Sharing → Permissions: add the account (or a group it belongs to) and grant the level the folder genuinely needs — Read for a documents drop, Change for a working folder. Then the Security tab: confirm the same account or group has the matching NTFS level (Read & execute / Modify). Click OK all the way out and test from the other PC immediately.
Resist the one-click seduction of Everyone — Full Control on both tabs. It 'works', in the same way removing a door works. Everyone on a network really means everyone — every device, every guest account, every future piece of malware running as any user. Grant the named account what it needs; the thirty extra seconds is the entire price of doing this properly.
If the share opens but one subfolder or file denies you, the two locks agree at the top and disagree deeper down: that item has its own NTFS entries that break the inheritance from its parent. On the host, open that item's Security tab, and either fix its list directly or use Advanced → Enable inheritance to let it take the parent's permissions again. Check files copied in from another PC or an old backup especially — they often arrive carrying a foreign set of permissions that names accounts which do not exist here.
Every check in this guide, shown live on a real Windows 11 PC — the complete network folder fix, step by step.
▶️ Watch Full VideoOwnership is not permission. Check that your account (or Administrators) actually appears in both the share permissions and the Security tab with the level you need, and that no Deny entry names a group you belong to — a Deny on Users beats your personal Allow.
Read. Over the network the two results combine and the more restrictive one wins. To write to the folder remotely you need Change or Full Control on the share and Modify on the NTFS side.
No — permissions live on the host with the folder. You must change them while signed in on the host (or have its administrator do it). Anything the connecting PC changes affects only its own behaviour, not the folder's rules.