How permissions are handled when you copy and move files and folders

This article describes how Windows Explorer handles file and folder permissions in different situations.

Original product version: В Windows 10 — all editions, Windows Server 2012 R2
Original KB number: В 310316

Summary

In Microsoft Windows 2000, in Windows Server 2003, and in Windows XP, you have the option of using either the FAT32 file system or the NTFS file system. When you use NTFS, you can grant permissions to your folders and files to control access to those objects. When you copy or move a file or folder on an NTFS volume, how Windows Explorer handles the permissions on the object varies, depending on whether the object is copied or moved within the same NTFS volume or to a different volume.

More information

By default, an object inherits permissions from its parent object, either at the time of creation or when it is copied or moved to its parent folder. The only exception to this rule occurs when you move an object to a different folder on the same volume. In this case, the original permissions are retained.

Additionally, note the following rules:

The Everyone group is granted Allow Full Control permissions to the root of each NTFS drive.

Deny permissions always take precedence over Allow permissions.

Explicit permissions take precedence over inherited permissions.

If NTFS permissions conflict, for example, if group and user permissions are contradictory, the most liberal permissions take precedence.

Permissions are cumulative.

To preserve permissions when files and folders are copied or moved, use the Xcopy.exe utility with the /O or the /X switch.

The object’s original permissions will be added to inheritable permissions in the new location.

To add an object’s original permissions to inheritable permissions when you copy or move an object, use the Xcopy.exe utility with the -O and -X switches.

To preserve existing permissions without adding inheritable permissions from the parent folder, use the Robocopy.exe utility, which is available in the Windows 2000 Resource Kit.

You can modify how Windows Explorer handles permissions when objects are copied or moved to another NTFS volume. When you copy or move an object to another volume, the object inherits the permissions of its new folder. However, if you want to modify this behavior to preserve the original permissions, modify the registry as follows.

This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, see How to back up and restore the registry in Windows.

Click Start, click Run, type regedit in the Open box, and then press ENTER.

Locate and then click the registry key: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer .

On the Edit menu, click Add Value, and then add the following registry value:

• Value name: ForceCopyAclwithFile
• Data type: DWORD
• Value data: 1

Exit Registry Editor.

You can modify how Windows Explorer handles permissions when objects are moved in the same NTFS volume. As mentioned, when an object is moved within the same volume, the object preserves its permissions by default. However, if you want to modify this behavior so that the object inherits the permissions from the parent folder, modify the registry as follows:

Click Start, click Run, type regedit, and then press ENTER.

Locate and then click the registry subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer .

On the Edit menu, click Add Value, and then add the following registry value:

• Value name: MoveSecurityAttributes
• Data type: DWORD
• Value data: 0

Exit Registry Editor.

Make sure that the user account that is used to move the object has the Change Permissions permission set. If the permission is not set, grant the Change Permissions permission to the user account.

The MoveSecurityAttributes registry value only applies to Windows XP and to Windows Server 2003. The value does not affect Windows 2000.

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.

File Security and Access Rights

Because files are securable objects, access to them is regulated by the access-control model that governs access to all other securable objects in Windows. For a detailed explanation of this model, see Access Control.

You can specify a security descriptor for a file or directory when you call the CreateFile, CreateDirectory, or CreateDirectoryEx function. If you specify NULL for the lpSecurityAttributes parameter, the file or directory gets a default security descriptor. The access control lists (ACL) in the default security descriptor for a file or directory are inherited from its parent directory. Note that a default security descriptor is assigned only when a file or directory is newly created, and not when it is renamed or moved.

To retrieve the security descriptor of a file or directory object, call the GetNamedSecurityInfo or GetSecurityInfo function. To change the security descriptor of a file or directory object, call the SetNamedSecurityInfo or SetSecurityInfo function.

The valid access rights for files and directories include the DELETE, READ_CONTROL, WRITE_DAC, WRITE_OWNER, and SYNCHRONIZE standard access rights. The table in File Access Rights Constants lists the access rights that are specific to files and directories.

Although the SYNCHRONIZE access right is defined within the standard access rights list as the right to specify a file handle in one of the wait functions, when using asynchronous file I/O operations you should wait on the event handle contained in a properly configured OVERLAPPED structure rather than using the file handle with the SYNCHRONIZE access right for synchronization.

The following are the generic access rights for files and directories.

Access right	Description
FILE_GENERIC_EXECUTE	FILE_EXECUTE FILE_READ_ATTRIBUTES STANDARD_RIGHTS_EXECUTE SYNCHRONIZE
FILE_GENERIC_READ	FILE_READ_ATTRIBUTES FILE_READ_DATA FILE_READ_EA STANDARD_RIGHTS_READ SYNCHRONIZE
FILE_GENERIC_WRITE	FILE_APPEND_DATA FILE_WRITE_ATTRIBUTES FILE_WRITE_DATA FILE_WRITE_EA STANDARD_RIGHTS_WRITE SYNCHRONIZE

Windows compares the requested access rights and the information in the thread’s access token with the information in the file or directory object’s security descriptor. If the comparison does not prohibit all of the requested access rights from being granted, a handle to the object is returned to the thread and the access rights are granted. For more information about this process, see Interaction between Threads and Securable Objects.

By default, authorization for access to a file or directory is controlled strictly by the ACLs in the security descriptor associated with that file or directory. In particular, the security descriptor of a parent directory is not used to control access to any child file or directory. The FILE_TRAVERSE access right can be enforced by removing the BYPASS_TRAVERSE_CHECKING privilege from users. This is not recommended in the general case, as many programs do not correctly handle directory traversal errors. The primary use for the FILE_TRAVERSE access right on directories is to enable conformance to certain IEEE and ISO POSIX standards when interoperability with Unix systems is a requirement.

The Windows security model provides a way for a child directory to inherit, or to be prevented from inheriting, one or more of the ACEs in the parent directory’s security descriptor. Each ACE contains information that determines how it can be inherited, and whether it will have an effect on the inheriting directory object. For example, some inherited ACEs control access to the inherited directory object, and these are called effective ACEs. All other ACEs are called inherit-only ACEs.

The Windows security model also enforces the automatic inheritance of ACEs to child objects according to the ACE inheritance rules. This automatic inheritance, along with the inheritance information in each ACE, determines how security restrictions are passed down the directory hierarchy.

Note that you cannot use an access-denied ACE to deny only GENERIC_READ or only GENERIC_WRITE access to a file. This is because for file objects, the generic mappings for both GENERIC_READ or GENERIC_WRITE include the SYNCHRONIZE access right. If an ACE denies GENERIC_WRITE access to a trustee, and the trustee requests GENERIC_READ access, the request will fail because the request implicitly includes SYNCHRONIZE access which is implicitly denied by the ACE, and vice versa. Instead of using access-denied ACEs, use access-allowed ACEs to explicitly allow the permitted access rights.

Another means of managing access to storage objects is encryption. The implementation of file system encryption in Windows is the Encrypted File System, or EFS. EFS encrypts only files and not directories. The advantage of encryption is that it provides additional protection to files that is applied on the media and not through the file system and the standard Windows access control architecture. For more information on file encryption, see File Encryption.

In most cases, the ability to read and write the security settings of a file or directory object is restricted to kernel-mode processes. Clearly, you would not want any user process to be able to change the ownership or access restriction on your private file or directory. However, a backup application would not be able to complete its job of backing up your file if the access restrictions you have placed on your file or directory does not allow the application’s user-mode process to read it. Backup applications must be able to override the security settings of file and directory objects to ensure a complete backup. Similarly, if a backup application attempts to write a backup copy of your file over the disk-resident copy, and you explicitly deny write privileges to the backup application process, the restore operation cannot complete. In this case also, the backup application must be able to override the access control settings of your file.

The SE_BACKUP_NAME and SE_RESTORE_NAME access privileges were specifically created to provide this ability to backup applications. If these privileges have been granted and enabled in the access token of the backup application process, it can then call CreateFile to open your file or directory for backup, specifying the standard READ_CONTROL access right as the value of the dwDesiredAccess parameter. However, to identify the calling process as a backup process, the call to CreateFile must include the FILE_FLAG_BACKUP_SEMANTICS flag in the dwFlagsAndAttributes parameter. The full syntax of the function call is the following:

This will allow the backup application process to open your file and override the standard security checking. To restore your file, the backup application would use the following CreateFile call syntax when opening your file to be written.

There are situations when a backup application must be able to change the access control settings of a file or directory. An example is when the access control settings of the disk-resident copy of a file or directory is different from the backup copy. This would happen if these settings were changed after the file or directory was backed up, or if it was corrupted.

The FILE_FLAG_BACKUP_SEMANTICS flag specified in the call to CreateFile gives the backup application process permission to read the access-control settings of the file or directory. With this permission, the backup application process can then call GetKernelObjectSecurity and SetKernelObjectSecurity to read and than reset the access-control settings.

If a backup application must have access to the system-level access control settings, the ACCESS_SYSTEM_SECURITY flag must be specified in the dwDesiredAccess parameter value passed to CreateFile.

Backup applications call BackupRead to read the files and directories specified for the restore operation, and BackupWrite to write them.