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.

Copy NTFS permissions to a NAS with Robocopy

I’m actually using Robocopy to copy a «home» folder with NTFS permissions to a NAS Synology. All theses equipment are on the domain, that will be named XXXXX in this post.

The permissions on the «home» folder are explicit, and not inherited from the parent folder. Also note that the SYNOLOGY NAS have the Windows Permissions activated.

The goal is to create a backup of this «home» folder to the NAS with the permissions.

Here is the Robocopy script that i’m using :

set rep_sync_DATA=\\SRV1\e$\home\
set rep_sync_NAS=\\NAS-SYNOLOGY01\test01\backup\home\

robocopy %rep_sync_DATA% %rep_sync_NAS% /MIR /SEC /ZB /NP /XF thumbs.db /R:2 /W:5 /log:%rep_log%\Synchronisation_backup_nas.txt

The Robocopy script works well, and the files are well copied. EXCEPT one. On my «home» source folder, we can find on the permission list the XXXXXX\Administrators group. (explicit permission)

But, unfortunately, once the folder is copied to the NAS, it change the XXXXX\Administrators group to NAS-SYSNOLOG01\Administrators. This folder take the local domain of the NAS instead of my AD domain.

Please note that this «domain change» is only applied to this group, and the others lambda groups are not impacted by this strange change. (example XXXXXX\Sales group on source folder will be copied as XXXXXX\Sales to the destination)

The same script works perfectly if the destination is a USB HDD for example. It only happens if I want to copy to the NAS.

Any idea to fix this issue ? I faced this issue twice, with SYNOLOGY and with NETAPP technology. Whatever soft I tried to copy (robocopy or others), the result is the same.

How to copy a directory with all permissions and junctions intact?

Is there any way to copy a directory with junctions in it and have it copy them as junctions, not the contents of the junction?

I’ll try to make a long story short, but I just spent a few hours cleaning up after robocopy and Windows 7’s hidden junctions. I have Windows 7 installed on a spare HD so I can play around with it, get used to it, test things and figure out how I want to set it up before taking the plunge and replacing XP full time.

Just as an experiment, I wanted to create a new user account, but put its user directory on another drive and use a symlink to point to it from C:\Users. I created a new user account called Test, logged in so that its home directory was created, and then logged out.

I discovered that moving or copying the files, either in explorer or a command prompt didn’t move or copy the directory junctions. I then tried robocopy since it has options to copy all security, owner and auditing info. There is also an option to «copy symbolic links versus the target.»

The exact command line I used was:
robocopy C:\Users\Test D:\Users /E /COPYALL /SL /R:0

First, it didn’t even copy the permissions, the few files it did copy inherited the destination parent directory’s permissions, and it added a strange permission which I’ll get to in a minute. It didn’t take long before it stopped with an error. I don’t remember the error because I’ve rebooted several times since then, and I don’t care to try again just to get the exact error message to post here.

What happened is that there is a hidden directory junction in C:\Users\Test\AppData\Local. The junctioin name is «Application Data» and it links to C:\Users\Test\AppData\Local (the same directory it’s in). This caused it to keep copying the «Application Data» folder into itself until the max folder name length was exceded and it stopped.

When I tried deleting the directory, I kept getting an error that it couldn’t delete the directory because it wasn’t empty. I had taken full control of the directory, but I still got the error and the directory (from what I could see) was empty.

Here’s where the strange permission comes in. For some reason, the copies of the «Application Data» directory were set to hidden/system, and had the Everyone group’s «List folder / read data» permission set to deny, which is why I couldn’t see them, even in administrator command prompt.

Once I got the permissions sorted out, I still couldn’t delete the directory because the name was too long. Windows kept telling me to rename it so it was shorter and try again. I finally managed to delete it by renaming a few «Application Data» directories to «a» and then moving part of it to another directory.

Using xcopy to copy files and folders and keeping the ntfs permissions

Overview

Xcopy while still included in Windows 10, XCOPY has been deprecated in favor of robocopy. XCOPY it has some great switches for doing things such as verifying the copy and only coping file that are newer than the destination.

Run: xcopy /? for a full list of switches but here are some useful ones if you are moving a large amount of data and want to keep NTFS permission.

Perform an Initial full copy preserving permissions

Copy files or folders that have changed since the initial copy

Switch Explanation

/X – Copies file audit settings and file ownership and ACL information.
/H – Copies hidden and system files.
/E – Copies directories and subdirectories, including empty ones.
/V – Verifies each new file.

/D – Copies files changed on or after the specified date (D:m-d-y).If no date is given, copies only those files whose source time is newer than the destination time.
/Y – Suppresses prompting to confirm you want to overwrite an existing destination file.

About The Author

Phil Eddies

I am an IT Systems Architect living in the UK. I have been working full time in IT since 2001 in support, administration and management roles. Big fan of retro gaming all things «geeky». Certifications include MCSA, MCSE, CCNA, Citrix CCA, ITIL.

8 Comments

Just what I was looking for thanks. I need to copy files retain the permissions and update changes before switching servers.

I would like to put one one more software here for consideration. As there are several programs which claim to be able to preserve the creation date of files. The best among those few programs which surely will do the trick is GS RichCopy 360. The software provides allot of other features like e-mail notification when job is done, scheduling your copy etc. Its very robust and reliable. I’ve been using it myself from a long time. You must give it a try. Hope this might help.

I am getting error following message on xcopy command : “security information not supported by destination file system” what is the solution?

What are the file systems of the source and destination? Are they both NTFS?

Copying NTFS permissions between folders

Update (November 2017): It has come my attention that this blog post has become the #1 search result for this topic. Therefore, I believe an update, even a minor one, is due.

Let’s assume you have created a folder called “Programs” in your D: volume and now you want its NTFS permissions to match that of “C:\Program Files”, thus having the same level of security.

Basic NTFS permission of “Program Files” folder in Windows 7

There are more than one ways. It can be accomplished with the following utilities:

1. icACLs and Notepad
2. Windows PowerShell
3. XCopy (not recommended)
4. Robocopy (not recommended)

Since the subject of NTFS security is one that requires intermediate knowledge of Windows, I will skip elementary details such as how to run a certain program with elevated privileges.

Windows terminology

Term	Acronym	Description
Discretionary access control list	DACL	The set of permissions on a given file, folder, registry key, network share or any other types of secured object in Windows. In case of files and folders stored on an NTFS disk, DACL is the set of NTFS permissions that says which user accounts or groups have which permissions.
System access control list	SACL	The set of auditing rules defined on a file, folder or other types of secured objects that support auditing.
Access control list	ACL	Refers to the whole set of security properties on a secured object (in our case, a file or folder), including the DACL, the SACL, the owner’s name, the integrity level and anything else that I might have missed.
Access control entry	ACE	Refers to an individual rule in a DACL or SACL.
Integrity level	IL	Also known as “mandatory label”, it is added in Windows Vista and is part of the DACL. But do not assume that what can copy DACL can also copy IL. Always investigate.
Owner	Every secured object can have an owner. The user account defined as the owner of a securable object has complete access to the object regardless of its DACL. However, if Disk Quota feature is enabled, the size of the files on an NTFS volume are deduced from the owner’s quota. Normally, ownership can be taken over by a user who has Take Ownership permission in DACL. Administrators and Backup Operators, by default, can also transfer the ownership to another user account.

icACLs and Notepad

This section shows how you can use icACLs in Windows 7 to transfer DACL and IL, but I believe there is a good chance this method works with Windows Vista, Windows 8, Windows 8.1 and all their Windows Server siblings.

icACLs was first introduced in Windows Server 2003 Service Pack 2, when IL didn’t exist. Nevertheless, icACLs copies IL too.

1. Open Command Prompt with administrative privileges. If you are using the default Windows settings, you will land in C:\Windows\System32 .
2. Navigate to an uncluttered folder in which you have write permission. You are about to create a file you don’t want to spend too much time looking for it.
3. Run the following command: icACLs «C:\Program Files» /save Perms.txt
4. Open Perms.txt in Notepad
5. Change the first line from “Program Files” to “Programs”. Be careful not to make any other changes.
6. Save the file and exit.
7. Run the following command: icACLs D:\ /restore Perms.txt

You can use /t switch with icACLs to save the permissions for all files and subfolders of the initial folder (in this example “Program Files”). Also please note that Program Files folder, by default, does not have an IL rule. But I am guessing system administrators would like to move permission on other folders as well, some of which may have IL rules.

I wonder what “icACLs” stands for. Maybe “I change ACLs”?

Windows PowerShell 5.x

This section explain how to use PowerShell v5.x to transfer DACL, SACL and object owner.

PowerShell is readily equipped with Get-Acl and Set-Acl commands, which can be piped as follows:

Get-Acl -Path | Set-Acl -Path

It tries to transfer all access control properties from the source file or folder to the destination file or folder. The following command:

Get-Acl -Path ‘C:\Program Files’ | Set-Acl -Path ‘D:\Programs’

…when executed with administrative privileges, does the trick for you. This is tested on Windows 10, but it will work on other version of Windows with PowerShell 5.x.

Windows PowerShell 4.0 and earlier

Get-Acl and Set-Acl were first introduced in PowerShell 2.0.

However, when I originally wrote this article, during my tests with PowerShell 4.0 and Windows 7, the following command:

Get-Acl -Path ‘C:\Program Files’ | Set-Acl -Path ‘D:\Programs’

…when executed without administrative privileges, generated the following error message:

When executed with admininstrative privileges, it generated the following error message:

Web searches for precedents indicated this to be a prevalent problem. At the time, this seemed a natural outcome. But one that made me take other measures.

Not every user account has the permission to modify every piece of ACL. Standard users have the right to transfer the DACL to a file or folder they own. So, the following code succeeds:

( Get-Item ‘C:\Program Files’ ).GetAccessControl(«Access») | Set-Acl -Path ‘D:\Programs’

Unfortunately, this commands does not seem to transfer the integrity level. In fact, it appears that .NET Framework deliberately avoids altering integrity levels. Native utilities like icACLs can do so, because they have access to Windows API.

Administrators can transfer SACLs, although by default, no such list is defined on “C:\Program Files”. So, this command succeeds when PowerShell is run with administrative privileges:

( Get-Item ‘C:\Program Files’ ).GetAccessControl(«Audit») | Set-Acl -Path ‘D:\Programs’

Administrators can also arbitrarily change ownership (“Owner”) to other users. But Program Files folder is owned by “NT SERVICE\TrustedInstaller” and Set-ACL seems not to be able to transfer it. But why bother? Windows installs some of its components in “Program Files”; hence it needs free reign in it. This is not the case with a custom folder like “D:\Programs”.

Robocopy

Starting with Windows 2000, RoboCopy became a Windows component as the successor of the venerable XCopy. According to Microsoft Support article 323275 and Robocopy documentation on TechNet, Robocopy can transfer DACL, SACL and ownership data. The following command transfers DACL only:

Robocopy «C:\Program Files» «D:\Programs» /COPY:S /SECFIX

This method is not tested. So, the risk is entirely yours.

XCopy

I am told that the following command “works” but I have no clue as to what part of ACL it transfers:

xcopy «C:\Program Files» «D:\Programs» /T /E /I /H /K /X /Y

This method is not tested. So, the risk is entirely yours. But if you want to know what each switch means, I am reproducing the relevant parts of XCopy help page for your perusal.