Files, folders and NTFS permissions

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.

NTFS permissions on the Security tab of the Documents folder, with SYSTEM, kmarflow and Administrators listed
The guest list of my Documents folder

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

PermissionWhat it allows
ReadOpen and copy files and folders, without changing them
Read & executeThe same, and run programs
List folder contentsSee what’s in a folder
WriteCreate files and folders, and add or remove data in files
ModifyAll of the above, and delete
Full controlEverything, 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:

CMD
whoami /user
Output
USER INFORMATION
----------------

User Name           SID
=================== ==============================================
pc-winit01\kmarflow S-1-5-21-3294108931-2130216864-1117364851-1002

I 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:

File Explorer saying you don't currently have permission to access this folder, with a Continue button
Note the word permanently

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:

Output
C:\Test3\AdminOnly BUILTIN\Administrators:(OI)(CI)(F)
                   NT AUTHORITY\SYSTEM:(OI)(CI)(F)

And after selecting Continue and approving it:

Output
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.

Advanced Security Settings for the Documents folder, with its owner and the Inherited from column
All three entries on my Documents folder come from C:\Users\kmarflow

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:

Advanced NTFS permissions of one entry, from Traverse folder and List folder to Change permissions and Take ownership
Show advanced permissions, on the kmarflow entry of a test folder

Most of them say what they do. Four are worth knowing by name:

Advanced permissionWhat it allows
Delete subfolders and filesDelete a folder’s contents
Read permissionsSee the guest list
Change permissionsChange the guest list
Take ownershipMake 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 doEntries it inheritedEntries set directly on the file
File Explorer: move on the same driveReplaced by the new folder’sStay
File Explorer: move to another driveReplaced by the new folder’sGone
File Explorer: copy, anywhereReplaced by the new folder’sGone
Command line: Move-Item or move, same driveStay, even the old inherited onesStay

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:

CMD
icacls C:\Users\kmarflow\Documents\owner-test.txt /grant kmarflow:R

And 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\Ngc

On 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:

CMD
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:

CMD
takeown /f C:\Test\locked.txt
Output
SUCCESS: 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:

CMD
icacls C:\Test\locked.txt /grant kmarflow:F

Only then did it open. For a whole folder, do both for everything inside. Without the second line, deleting my locked test folder still failed:

CMD
takeown /f C:\Test\Locked /r /d y
icacls C:\Test\Locked /grant Administrators:F /T

The 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:

PowerShell
$acl = Get-Acl C:\Test\locked.txt
$acl.SetOwner([System.Security.Principal.NTAccount]'BUILTIN\Administrators')
Set-Acl C:\Test\locked.txt $acl

And to give yourself access:

PowerShell
$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 $acl

Both 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:

CMD
icacls C:\Users\kmarflow\Documents
Output
C:\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 files

It looks cryptic at first, but it’s only letters:

LetterMeaningLetterMeaning
FFull access(I)Inherited from the parent
MModify(OI)Files in this folder inherit it
RXRead and execute(CI)Subfolders inherit it
RRead-only(IO)Applies to children, not this folder itself
WWrite-only(NP)Doesn’t pass further down
DDelete
NNo access

To grant someone access to a folder and everything below it:

CMD
icacls C:\Test\Shared /grant kmarflow:(OI)(CI)M

And if you’ve made a mess of a test folder, this replaces its permissions with the default inherited ones:

CMD
icacls C:\Test\Shared /reset /T

Both 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:

PowerShell
(Get-Acl C:\Users\kmarflow\Documents).Access | Format-Table IdentityReference, FileSystemRights, AccessControlType, IsInherited
Output
IdentityReference      FileSystemRights AccessControlType IsInherited
-----------------      ---------------- ----------------- -----------
NT AUTHORITY\SYSTEM         FullControl             Allow        True
BUILTIN\Administrators      FullControl             Allow        True
PC-WINIT01\kmarflow         FullControl             Allow        True

Same 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:

PowerShell
$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 $acl

For icacls /reset /T there’s no tidy PowerShell equivalent, so that one stays with icacls.

Fixing “access denied”: what to try, in order

  1. Check who you are. Are you signed in as the account you think you are?
  2. Try with administrator rights. If it’s a folder, File Explorer may offer Continue. Remember that this adds you to the list permanently.
  3. Check the Security tab. Is your account or one of your groups listed?
  4. 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.
  5. 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.


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *