How to Set File and Folder Permissions in Windows

Comes in handy when sharing a computer with family or coworkers

Normally, you don’t have to worry about permissions in Windows because that’s already taken care of by the operating system. Each user has their own profile and their own set of permissions, which prevents unauthorized access to files and folders.

There are times, however, when you might want to manually configure the permissions on a set of files or folders in order to prevent other users from accessing the data. This post is assuming the other “people” also have access to the same computer you are using.

If not, you may as well just encrypt your hard drive and that’s it. However, when others can access the computer, like family or friends, then permissions can come in handy.

Of course, there are other alternatives like hiding files and folders using file attributes or by using the command prompt to hide data. You can even hide an entire drive in Windows if you like.

If you are looking to set permissions in order to share files with others, check out my post on creating a hidden network share or how to share files across computers, tablets and phones.

Data Security

The only other occasion where you will need to mess around with folder or file permissions is when you get a Permission Denied error when trying to access data. This means you can take ownership of files that don’t belong to your current user account and still access them.

This is important because it means that setting permissions on a file or folder does not guarantee the security of that file or folder. In Windows, an administrator on any Windows PC can override the permissions on a set of files and folders by taking ownership of them. Once you have ownership, you can set your own permissions.

So what does this mean in English? Basically, if you have data you don’t want others to see, then you should either not store it on that computer at all or you should use an encryption tool like TrueCrypt.

For those tech-savvy readers, you’ll probably be saying “Hey wait, TrueCrypt has been discontinued due to security vulnerabilities and shouldn’t be used!” Well, that is correct, however, TrueCrypt has been audited by an independent organization and Phase I and Phase II have been completed.

The only version you should download is TrueCrypt 7.1a, the one that has been uploaded to a verified mirror on GitHub. If you are not comfortable at all using TrueCrypt, the only other suggestion I have is VeraCrypt, which was the successor to TrueCrypt, but fixed many of the flaws.

File and Folder Permissions

Now that we got all of that out of the way, let’s talk about permissions in Windows. Every file and every folder in Windows has its own set of permissions. Permissions can be broken down into Access Control Lists with users and their corresponding rights. Here is an example with the user list at the top and the rights at the bottom:

Permissions are also either inherited or not. Normally in Windows, every file or folder gets their permissions from the parent folder. This hierarchy keeps going all the way up to the root of the hard drive. The simplest permissions have at least three users: SYSTEM, currently logged in user account and the Administrators group.

These permissions usually come from the C:\Users\Username folder on your hard drive. You can access these permissions by right-clicking on a file or folder, choosing Properties and then clicking on the Security tab. To edit permissions for a particular user, click on that user and then click the Edit button.

Note that if the permissions are greyed out, like in the example above, the permissions are being inherited from the containing folder. I’ll talk about how you can remove inherited permissions further below, but first let’s understand the different types of permissions.

Permission Types

There are basically six types of permissions in Windows: Full Control, Modify, Read & Execute, List Folder Contents, Read, and Write. List Folder Contents is the only permission that is exclusive to folders. There are more advanced attributes, but you’ll never need to worry about those.

So what do each of these permissions mean? Well, here is a nice chart from Microsoft’s website that breaks on what each permissions means for files and for folders:

Now that you understand what each permission controls, let’s take a look at modifying some permissions and checking out the results.

Editing Permissions

Before you can edit any permissions, you have to have ownership of the file or folder. If the owner is another user account or a system account like Local System or TrustedInstaller, you won’t be able to edit the permissions.

Read my previous post on how to take ownership of files and folders in Windows if you are currently not the owner. Now that you are the owner, let’s get a few more things out of the way:

If you right-click on a file or folder, choose Properties and click on the Security tab, we can now try to edit some permissions. Go ahead and click the Edit button to get started.

At this point, there are a couple of things you can do. Firstly, you’ll notice that the Allow column is probably greyed out and can’t be edited. This is because of the inheritance I was talking about earlier.

However, you can check items on the Deny column. So if you just want to block access to a folder for a specific user or group, click the Add button first and once added, you can check the Deny button next to Full Control.

When you click the Add button, you have to type in the user name or group name into the box and then click on Check Names to make sure it’s correct. If you don’t remember the user or group name, click on the Advanced button and then just click Find Now. It will show you all the users and groups.

Click OK and the user or group will be added to the access control list. Now you can check the Allow column or Deny column. As mentioned, try to use Deny only for users instead of groups.

Now what happens if we try to remove a user or group from the list. Well, you can easily remove the user you just added, but if you try to remove any of the items that were already there, you’ll get an error message.

In order to disable inheritance, you have to go back to the main Security tab for the file or folder and click on the Advanced button at the bottom.

On Windows 7, you’ll one extra tab for Owner. In Windows 10, they just moved that to the top and you have to click Change. Anyway, in Windows 7, click on Change Permissions at the bottom of the first tab.

On the Advanced Security Settings dialog, uncheck the Include inheritable permissions from this object’s parent box.

When you do that, another dialog box will popup and it will ask you whether you want to convert the inherited permissions to explicit permissions or whether you just want to remove all the inherited permissions.

Unless you really know exactly what permissions you want, I suggest choosing Add (explicit permissions) and then just removing whatever you don’t want afterwards. Basically, clicking on Add will keep all the same permissions, but now they won’t be greyed out and you can click Remove to delete any user or group. Clicking Remove, will start you off with a clean slate.

In Windows 10, it looks slightly different. After clicking on the Advanced button, you have to click on Disable Inheritance.

When you click on that button, you’ll get the same options as in Windows 7, but just in a different form. The Convert option is the same as Add and the second option is the same as Remove.

The only thing you have to understand now is the Effective Permissions or Effective Access tab. So what is effective permissions? Well, let’s see the example above. I have a text file and my account, Aseem, has Full Control. Now what if I add another item to the list so that the group Users is denied Full Control.

The only problem here is that the Aseem account is also part of the Users group. So I have Full Control in one permission and Deny in another, which one wins? Well, as I mentioned above, Deny always overrides Allow, so Deny will win, but we can also confirm this manually.

Click on Advanced and go to the Effective Permissions or Effective Access tab. In Windows 7, click the Select button and type in the user or group name. In Windows 10, click the Select a user link.

In Windows 7, once you select the the user, it will instantly show the permissions in the list box below. As you can see, all of the permissions are unchecked, which makes sense.

In Windows 10, you have to click the View effective access button after selecting the user. You’ll also get a nice red X for no access and a green check mark for allowed access, which is a bit easier to read.

So now you pretty much know all there is to know about Windows file and folder permissions. It does take some playing around yourself in order to get the hang of it all.

The main points to understand are that you need to be the owner in order to edit permissions and that any administrator can take ownership of files and folders regardless of the permissions on those objects. If you have any questions, feel free to post a comment. Enjoy!

Founder of Online Tech Tips and managing editor. He began blogging in 2007 and quit his job in 2010 to blog full-time. He has over 15 years of industry experience in IT and holds several technical certifications. Read Aseem’s Full Bio

File Permissions for WSL

This page details how Linux file permissions are interpreted across the Windows Subsystem for Linux, especially when accessing resources inside of Windows on the NT file system. This documentation assumes a basic understanding of the Linux file system permissions structure and the umask command.

When accessing Windows files from WSL the file permissions are either calculated from Windows permissions, or are read from metadata that has been added to the file by WSL. This metadata is not enabled by default.

WSL metadata on Windows files

When metadata is enabled as a mount option in WSL, extended attributes on Windows NT files can be added and interpreted to supply Linux file system permissions.

WSL can add four NTFS extended attributes:

Attribute Name	Description
$LXUID	User Owner ID
$LXGID	Group Owner ID
$LXMOD	File mode (File systems permission octals and type, e.g: 0777)
$LXDEV	Device, if it is a device file

Additionally, any file that is not a regular file or directory (e.g: symlinks, FIFOs, block devices, unix sockets, and character devices) also have an NTFS reparse point. This makes it much faster to determine the kind of file in a given directory without having to query its extended attributes.

File Access Scenarios

Below is a description of how permissions are determined when accessing files in different ways using the Windows Subsystem for Linux.

Accessing Files in the Windows drive file system (DrvFS) from Linux

These scenarios occur when you are accessing your Windows files from WSL, most likely via /mnt/c .

Reading file permissions from an existing Windows file

The result depends on if the file already has existing metadata.

DrvFS file does not have metadata (default)

If the file has no metadata associated with it then we translate the effective permissions of the Windows user to read/write/execute bits and set them to the this as the same value for user, group, and other. For example, if your Windows user account has read and execute access but not write access to the file then this will be shown as r-x for user, group and other. If the file has the ‘Read Only’ attribute set in Windows then we do not grant write access in Linux.

The file has metadata

If the file has metadata present, we simply use those metadata values instead of translating effective permissions of the Windows user.

Changing file permissions on an existing Windows file using chmod

The result depends on if the file already has existing metadata.

chmod file does not have metadata (default)

Chmod will only have one effect, if you remove all the write attributes of a file then the ‘read only’ attribute on the Windows file will be set, since this is the same behaviour as CIFS (Common Internet File System) which is the SMB (Server Message Block) client in Linux.

chmod file has metadata

Chmod will change or add metadata depending on the file’s already existing metadata.

Please keep in mind that you cannot give yourself more access than what you have on Windows, even if the metadata says that is the case. For example, you could set the metadata to display that you have write permissions to a file using chmod 777 , but if you tried to access that file you would still not be able to write to it. This is thanks to interopability, as any read or write commands to Windows files are routed through your Windows user permissions.

Creating a file in DriveFS

The result depends on if metadata is enabled.

Metadata is not enabled (default)

The Windows permissions of the newly created file will be the same as if you created the file in Windows without a specific security descriptor, it will inherit the parent’s permissions.

Metadata is enabled

The file’s permission bits are set to follow the Linux umask, and the file will be saved with metadata.

Which Linux user and Linux group owns the file?

The result depends on if the file already has existing metadata.

User file does not have metadata (default)

In the default scenario, when automounting Windows drives, we specify that the user ID (UID) for any file is set to the user ID of your WSL user and the group ID (GID) is set to the principal group ID of your WSL user.

User file has metadata

The UID and GID specified in the metadata is applied as the user owner and group owner of the file.

Accessing Linux files from Windows using \\wsl$

Accessing Linux files via \\wsl$ will use the default user of your WSL distribution. Therefore any Windows app accessing Linux files will have the same permissions as the default user.

Creating a new file

The default umask is applied when creating a new file inside of a WSL distribution from Windows. The default umask is 022 , or in other words it allows all permissions except write permissions to groups and others.

Accessing files in the Linux root file system from Linux

Any files created, modified, or accessed in the Linux root file system follow standard Linux conventions, such as applying the umask to a newly created file.

Configuring file permissions

You can configure your file permissions inside of your Windows drives using the mount options in wsl.conf. The mount options allow you to set umask , dmask and fmask permissions masks. The umask is applied to all files, the dmask is applied just to directories and the fmask is applied just to files. These permission masks are then put through a logical OR operation when being applied to files, e.g: If you have a umask value of 023 and an fmask value of 022 then the resulting permissions mask for files will be 023 .

Please see the Configure per distro launch settings with wslconf article for instructions on how to do this.