Inherited permissions are not automatically updated when you move folders
This article was previously published under Q320246
An Access Control List (ACL) may show permissions that are marked as having been inherited from the parent, but the parent itself may not have these permissions configured in its ACL. Note that this symptom may occur even though inheritance is still enabled. Any subsequent change tothe parent folder's ACL causes the child's ACL to receive theinherited permissions. Also, any attempt to change the ACL of the child causes the inheritance to be applied (unless the change marks theACL as being protected from inheritance). This behavior may be surprising if the inheritance state had not been noted before you start to edit the ACL.
Note This behavior cannot be caused by moving a folder when you are running a Windows Vista based computer. The move operation now works because the folder or the file can inherit ACL of the target folder or file. The folder or file also has permissions that are marked as having been inherited from the parent. This is a change by design from Windows XP to Windows Vista and Windows Server 2008.
This behavior may be caused by moving a folder. When you move a folder, the ACL is not changed, and the inherited permissions are not updated. Note that "move" in the context of this article always means to move within the same volume.
When you move a file or folder, the ACL is also moved and is not changed in any way. Even when inheritance is enabled for this folder, the inherited permissions are not automatically updated. The ACL will be updated the next time you change permissions, and this forces the parent to propagate its permissions.
This behavior can also be caused by:
- Setting the permissions of a parent folder by using CACLS does not propagate to the subfolders. Note that the /T option does not mean to propagate the rights by using inheritance, but to overwrite all ACLs.
- Setting the permissions of a parent folder by using an API that does not automatically propagate inheritance (like Adssecurity.dll).For additional information, click the article number below to view the article in the Microsoft Knowledge Base:266461 HOWTO:Set Automatic Inheritance of File/Folder Permissions- ADSI
- Restoring from a backup to a different location.
To avoid unexpected permission changes, set the ACL of the file/folder to "protected" before moving when you want to keep the settings. Otherwise, manually update the ACL of the moved file/folder by using the explorer ACL editor. Disable and than enable inheritance again to force the ACL to be updated with the right inherited permissions. You may also use a VBScript to automate this process. For additional information about how to do so, click the article number below to view the article in the Microsoft Knowledge Base:
279682 HOWTO: Use ADsSecurity.dll to Add an ACE to an NTFS Folder
This behavior is by design. This behavior does not occur due to the design modification in Windows Vista.
Steps to Reproduce the Behavior
- Create a "test1" folder with "everyone:read" and "users:change" permissions.
- Create a "test1\sub" subfolder and enable the inheritance from parent (default). This folder should show "everyone:read" and "users:change" as inherited permissions.
- Create another folder "test2" with only "administrators:full control" permissions.
- Move the "sub" subfolder to "test2".
- View the permissions on "test2\sub" to see "everyone:read" and "users:change" as inherited permissions although the parents permission is "administrators:full control".
- Add another group/user (such as guest) to the ACL of "sub" granting, for example, Read access using the explorer ACL editor. After you click Apply, "everyone:read" and "users:change" is removed, and only "administrators:full control" is displayed as inherited permissions beside the one you just added.
Article ID: 320246 - Last Review: 03/02/2007 00:34:00 - Revision: 3.7
Microsoft Windows Server 2003, Web Edition, Microsoft Windows Server 2003, Standard Edition (32-bit x86), Microsoft Windows Server 2003, Enterprise Edition (32-bit x86), Microsoft Windows XP Professional, Microsoft Windows 2000 Server, Microsoft Windows 2000 Advanced Server, Microsoft Windows 2000 Datacenter Server, Microsoft Windows 2000 Professional Edition, Microsoft Windows NT 4.0 Service Pack 4, Microsoft Windows NT 4.0 Service Pack 5, Microsoft Windows NT 4.0 Service Pack 6, Microsoft Windows NT 4.0 Service Pack 6a, Windows Server 2008 Datacenter without Hyper-V, Windows Server 2008 Enterprise without Hyper-V, Windows Server 2008 for Itanium-Based Systems, Windows Server 2008 Standard without Hyper-V, Windows Server 2008 Datacenter, Windows Server 2008 Enterprise, Windows Server 2008 Standard, Windows Web Server 2008
- kbenv kbui kbprb KB320246