You double-click a folder and Windows says “You don’t currently have permission to access this folder”. On your own PC. As an administrator. So who gets to decide that?
Now that you know about accounts and where files live, we can connect the two. This is a longer one, so top up that coffee.
Every file has a guest list
Right-click a file or folder, select Properties, then the Security tab. At the top is a list of users and groups, and below that is what the selected one may do.
That’s the file’s guest list, and every file and folder on an NTFS drive has one. FAT32 and exFAT drives have no such lists, so many USB sticks don’t work like this at all. How those file systems differ is in Disks, partitions and NTFS, in the How Windows Works course.

On an exFAT test drive, a file’s properties simply have no Security tab, and icacls puts it plainly: “No permissions are set. All users have full control.”
What NTFS permissions mean
| Permission | What it allows |
|---|---|
| Read | Open and copy files and folders, without changing them |
| Read & execute | The same, and run programs |
| List folder contents | See what’s in a folder |
| Write | Create files and folders, and add or remove data in files |
| Modify | All of the above, and delete |
| Full control | Everything, including changing the permissions and owner |
Each of these is either allowed or denied, and four rules decide the outcome:
- Permissions add up. If you’re in two groups, you get what both allow.
- What’s set directly comes first. Windows checks entries set on the file itself before those it inherited.
- Deny comes before allow at each of those levels.
- If nothing allows it, it’s refused. You don’t need a Deny to be locked out, not being on the list is enough.
You’ll often hear “deny always wins”, and Microsoft’s own permissions page says so too. But going by Microsoft’s documented order, an Allow set directly on a file gets checked before a Deny inherited from its folder. I tried it on my test machine with a test user: Deny inherited from the folder, and the file refuses to open. Add an Allow directly on the file, and it opens. So that’s the one exception.
Who is who: groups and SIDs
The list holds names like kmarflow, Administrators and Users. Giving rights to a group means everyone in it gets them, which beats listing people one by one.
Behind each name is a security identifier (SID), a unique value that identifies a user or group, and once a SID has been used, it’s never used again. It’s an ID number, and the name is only a label on top. So deleting an account and creating a new one with the same name doesn’t bring back its access: same name, different person, as far as Windows is concerned. To see your own:
whoami /userUSER INFORMATION
----------------
User Name SID
=================== ==============================================
pc-winit01\kmarflow S-1-5-21-3294108931-2130216864-1117364851-1002I tried that on my test machine: a user with access to a folder, deleted and created again under the same name. The new one got a different SID and was refused. In the folder’s list, the old entry was left behind as just a SID with no name, and if you ever see one of those, that’s what it is: a permission for an account that no longer exists.
How Windows decides
When you sign in, Windows creates an access token for you, a sort of ID badge holding your SID, your groups’ SIDs and your privileges. Every program you run gets a copy of it.
So when a program tries to open a file, Windows holds the program’s badge against the file’s list. It goes through the entries one by one, until one denies what was asked for, or until everything asked for has been allowed. If it reaches the end and something still hasn’t been allowed, the answer is no.
It’s also why being an administrator doesn’t always help. Until you approve a UAC prompt, your programs run with a badge that has the administrator rights taken off.
That’s the message from the start of this article. Try to open a folder only Administrators may read, and File Explorer offers you this:

Continue isn’t a one-time pass. It asks for your approval, and then changes the folder’s guest list. I checked with icacls on a test folder. Before:
C:\Test3\AdminOnly BUILTIN\Administrators:(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(F)And after selecting Continue and approving it:
C:\Test3\AdminOnly BUILTIN\Administrators:(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(F)
PC-WINIT01\kmarflow:(OI)(CI)(F)So your own account now has Full control, for good, until someone takes it off again. That’s fine for your own folder, but it’s a real change, and not one to click through in folders that aren’t yours.
Inheritance: why you rarely set any of this
Nobody sets permissions on every single file, thankfully. By default, a file or folder inherits from the folder it’s in. On the Security tab, select Advanced, and the list shows you where each entry comes from.

This screen also shows the file’s Owner, with a Change link, and it has an Effective Access tab.
An explicit entry set on the file itself takes priority over an inherited one. You can also turn inheritance off for a folder with Disable inheritance on that Advanced screen, but that’s also a great way to lock yourself out.
Advanced permissions: what the six are made of
The six permissions on the Security tab are really bundles. To see what’s in one, go to Properties > Security > Advanced, select an entry and select View, or Edit where you’re allowed to change it. That shows the entry with its basic permissions, and in the top right corner is a link called Show advanced permissions. Select it, and the bundles come apart:

Most of them say what they do. Four are worth knowing by name:
| Advanced permission | What it allows |
|---|---|
| Delete subfolders and files | Delete a folder’s contents |
| Read permissions | See the guest list |
| Change permissions | Change the guest list |
| Take ownership | Make yourself the owner, more on that below |
That’s also the real difference between Modify and Full control. Going by Microsoft’s definitions, Modify includes reading the list, but not Change permissions, Take ownership or Delete subfolders and files. Full control has everything.
Copying and moving: the rule that surprises people
Microsoft’s page on this says a file moved within the same drive keeps its original permissions, and that everything else inherits from the new folder. That page names only Windows XP-era versions though, so I tried it on 25H2, and the answer depends on what you move it with:
| What you do | Entries it inherited | Entries set directly on the file |
|---|---|---|
| File Explorer: move on the same drive | Replaced by the new folder’s | Stay |
| File Explorer: move to another drive | Replaced by the new folder’s | Gone |
| File Explorer: copy, anywhere | Replaced by the new folder’s | Gone |
Command line: Move-Item or move, same drive | Stay, even the old inherited ones | Stay |
That last row is the classic trap. Someone moves a file into a shared folder with a script, everything looks right, and your colleague still can’t open it, because it kept the permissions of its old folder. And the second row of the table has its own trap: if you set a special permission directly on a file, a copy won’t have it.
Ownership
Every file and folder also has an owner, normally whoever created it. You’ll find it at the top of the Advanced screen, with a Change link next to it.
What the owner gets
The owner can always change the permissions. Microsoft states it for owners in general, and it holds even when the owner isn’t on the list at all. I tried it with a file of my test user, with every entry removed. Opening it: “Access to the path is denied”. But as the owner, without administrator rights, this still worked:
icacls C:\Users\kmarflow\Documents\owner-test.txt /grant kmarflow:RAnd then the file opened. So ownership isn’t access as such. It’s the right to hand out access, yourself included.
Taking ownership
Administrators have a right called Take ownership of files or other objects. Microsoft describes it as taking control of any object, regardless of its permissions. That’s the way back in when even an administrator gets “access denied”.
The Ngc folder is a good example. It belongs to Windows Hello, and deleting it is a common suggestion when a PIN stops working, as in this question on Microsoft Q&A. It’s here:
C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\NgcOn my test machine its owner is LOCAL SERVICE, and even from a terminal running as administrator, listing, renaming and deleting it all ended in “Access to the path is denied”. Only after taking ownership did it go:
takeown /f C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc /r /d y/r includes everything inside, and /d y answers yes for each folder you can’t open, which also gives you full control of it. After that, deleting the folder worked. My test machine has no PIN set up, so the folder was empty. With files in it, plan for the second step below as well.
Ownership alone doesn’t open the door
Taking ownership doesn’t give you access to the files themselves. On my test machine, with a file only SYSTEM could open:
takeown /f C:\Test\locked.txtSUCCESS: The file (or folder): "C:\Test\locked.txt" now owned by user "PC-WINIT01\kmarflow".Reading it still said “Access to the path is denied”, until I also gave myself access, in a terminal running as administrator:
icacls C:\Test\locked.txt /grant kmarflow:FOnly then did it open. For a whole folder, do both for everything inside. Without the second line, deleting my locked test folder still failed:
takeown /f C:\Test\Locked /r /d y
icacls C:\Test\Locked /grant Administrators:F /TThe same in PowerShell
PowerShell has no takeown of its own, but Get-Acl and Set-Acl do both steps, one file or folder at a time. To take ownership:
$acl = Get-Acl C:\Test\locked.txt
$acl.SetOwner([System.Security.Principal.NTAccount]'BUILTIN\Administrators')
Set-Acl C:\Test\locked.txt $aclAnd to give yourself access:
$acl = Get-Acl C:\Test\locked.txt
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTIN\Administrators', 'FullControl', 'Allow')
$acl.AddAccessRule($rule)
Set-Acl C:\Test\locked.txt $aclBoth worked in Windows PowerShell running as administrator, on a file only SYSTEM could open, and again, the file only opened after the second one. For a whole folder tree, takeown /r is far less typing. One more difference: as the owner without administrator rights, icacls /grant worked for me where Set-Acl refused, with an error about a missing SeSecurityPrivilege.
Hands off the Windows folders
My advice: don’t take ownership of system folders or change their permissions just because something says access denied. Keep this to your own files on a data drive, such as those from an old PC or another account, and to fixes like the Ngc one, where you know what the folder is for.
Reading permissions from the command line
icacls shows the same list as text, which is handy to copy into a support request:
icacls C:\Users\kmarflow\DocumentsC:\Users\kmarflow\Documents NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
BUILTIN\Administrators:(I)(OI)(CI)(F)
PC-WINIT01\kmarflow:(I)(OI)(CI)(F)
Successfully processed 1 files; Failed processing 0 filesIt looks cryptic at first, but it’s only letters:
| Letter | Meaning | Letter | Meaning | |
|---|---|---|---|---|
F | Full access | (I) | Inherited from the parent | |
M | Modify | (OI) | Files in this folder inherit it | |
RX | Read and execute | (CI) | Subfolders inherit it | |
R | Read-only | (IO) | Applies to children, not this folder itself | |
W | Write-only | (NP) | Doesn’t pass further down | |
D | Delete | |||
N | No access |
To grant someone access to a folder and everything below it:
icacls C:\Test\Shared /grant kmarflow:(OI)(CI)MAnd if you’ve made a mess of a test folder, this replaces its permissions with the default inherited ones:
icacls C:\Test\Shared /reset /TBoth of these need a terminal running as administrator, unless it’s your own folder. In Command Prompt they work exactly as shown. In PowerShell, put single quotes around the part with the brackets, 'kmarflow:(OI)(CI)M', or PowerShell tries to run what’s inside.
The PowerShell way
PowerShell has its own commands for this, Get-Acl and Set-Acl. Reading the list:
(Get-Acl C:\Users\kmarflow\Documents).Access | Format-Table IdentityReference, FileSystemRights, AccessControlType, IsInheritedIdentityReference FileSystemRights AccessControlType IsInherited
----------------- ---------------- ----------------- -----------
NT AUTHORITY\SYSTEM FullControl Allow True
BUILTIN\Administrators FullControl Allow True
PC-WINIT01\kmarflow FullControl Allow TrueSame list, in words instead of letters. Granting is more typing than with icacls: you read the list, add an entry and write it back. This gives Users Modify on a folder and everything below it, like the (OI)(CI)M example above:
$acl = Get-Acl C:\Test\Shared
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTIN\Users', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
$acl.AddAccessRule($rule)
Set-Acl C:\Test\Shared $aclFor icacls /reset /T there’s no tidy PowerShell equivalent, so that one stays with icacls.
Fixing “access denied”: what to try, in order
- Check who you are. Are you signed in as the account you think you are?
- Try with administrator rights. If it’s a folder, File Explorer may offer Continue. Remember that this adds you to the list permanently.
- Check the Security tab. Is your account or one of your groups listed?
- Check whether it’s in use. A file open in another program refuses changes for a completely different reason. Read the message: “because it is being used by another process” has nothing to do with permissions, so close the program, and leave the Security tab alone.
- As a last resort, and only for your own files, take ownership and give yourself access.
That’s it for you, your files and who can open them. Now to what’s actually running on your PC: Task Manager, processes and startup apps.
References
Tested on Windows 11 25H2, build 26200.9711, in a virtual machine: the Security tab, the advanced permissions view, copy and move behavior, what an owner can do, taking ownership with takeown and with Set-Acl, the Ngc folder (without a PIN set up), all commands in Command Prompt or Windows PowerShell as shown, and the access denied scenarios.
- File System Functionality Comparison, Microsoft Learn, last updated 2023-03-27.
- Permissions when you copy and move files, Microsoft Learn, last updated 2026-02-12. Names only older Windows versions, so its rules were checked on the test machine.
- Security Identifiers, Microsoft Learn, last updated 2025-07-10.
- Access Tokens, Microsoft Learn, last updated 2025-07-08.
- How AccessCheck Works, Microsoft Learn, last updated 2021-01-07.
- DACLs and ACEs, Microsoft Learn, last updated 2025-07-08.
- Order of ACEs in a DACL, Microsoft Learn, last updated 2021-01-07.
- FileSystemRights Enum, Microsoft Learn, no date shown. Source of the permission definitions.
- File Access Rights Constants, Microsoft Learn, last updated 2021-01-07.
- ACE Inheritance, Microsoft Learn, last updated 2021-01-07.
- File Security and Access Rights, Microsoft Learn, last updated 2025-07-09.
- How User Account Control works, Microsoft Learn, last updated 2026-04-23.
- icacls, Microsoft Learn, last updated 2025-06-09.
- takeown, Microsoft Learn, last updated 2025-11-04.
- Take ownership of files or other objects, Microsoft Learn, last updated 2017-04-19. Archived and written for Windows 10; the right itself was checked with
whoami /privon the test machine. - Owner of a New Object, Microsoft Learn, last updated 2021-01-07. The owner’s implicit right to change the permissions.
- Get-Acl, Microsoft Learn, no date shown.
- Set-Acl, Microsoft Learn, no date shown.
- User forgot PIN – no way to reset, can’t take ownership of NGC folder, Microsoft Q&A, asked 2021-03-09. A user’s question, not Microsoft documentation.
Leave a Reply