Ocassionally, we have the problem that a file has permissions different from the folder where it's in.

Now I found out that there's a KB article explaining the reason behind this:

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.

So the user moved the file from one folder to another and the permissions from the original folder were retained.

My question now is: why does this exception exist? What's the reasoning behind this?

3 Answers 3


I have explained this in a blog post http://think-like-a-computer.com/2011/07/24/moving-files-on-the-same-ntfs-volume-does-inherit-permissions/ but it is also explained below.

When a file is copied, it has to create a brand new file and assign it a new set of permissions, so it gets the permissions from the parent folder as you know.

When a file is moved to another volume, what actually happens is that it is copied to the new volume and the old file is deleted. So the same process is repeated as above as it is a new file again and needs permissions set.

When the file is moved within the same volume, nothing really happens (at the disk level). It just changes the logical path location of the file. The actual data and physical file on the disk hasn't been touched or changed. Ever noticed when you move a 5GB file to another folder on the same drive, it is done almost instantly? This is why, because it actually hasn't moved but the pointer to where the file logically exists has changed. As it was not modified in any way, the permissions don't change also.

This is the reason for this behaviour.

Edit: Something I forgot to mention... The MS article isn't entirely accurate. MS quote:

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.

The above quote only applies to objects that have been given EXPLICITLY defined sec permissions (turn inheritance off). As mentioned in my comments, it is all about keeping the ACL entries as efficient as possible. Consider the following example:

To keep the explanation simple, let's say you have a folder set to allow users modify rights only. Below this, there're thousands of files and none of them have explicit permissions set. It isn't very efficient to create ACLs for each file as they are exactly the same perms so it sets ONE ACL entry for the folder. This next bit is very IMPORTANT to understand; the files themselves have NO ACL PERMS. So when you move any of these file into a new folder in the same volume, MS claims the perms move with it (as above quote). Ask yourself this....how? There were no perms on the file in the first place to move across. This is actually incorrect and I just tested it now to confirm it. Let's say the destination folder you are moving the file to has perms to allow the everyone group modify rights only. Well since the file has no ACL directly, it inherits the ACL of the parent folder. This means the perms have changed from users modify (old folder) to everyone modify (new folder).

Notice the difference?? This time around, moving a file to another folder in the same volume actually has changed the perms, something MS says it doesn't do. Have I just found a mistake in MS documentation since 2000 lol??

Now look at the same scenario when using explicit permissions. If you set explicit permissions on a file within this folder (inheritance turned off) which, for example, denies users read access, it now creates A NEW ACL entry specifically for this file. Now when you move the file to a new location, it has an ACL entry directly related to it. In this case, moving a file to a new location in the same volume RETAINS its permissions (as MS claims)!

  • +1 Both are good answers, but yours is more to the point. I like your comment about how the 5GB file moves instantly. Good visual.
    – KCotreau
    Jul 20, 2011 at 11:59
  • I tend to think that "no copy is happening" is the main reason why ACL isn't touched.
    – VVS
    Jul 20, 2011 at 12:54
  • 1
    There's no technical reason a change to the filesystem table shouldn't affect the corresponding ACL entry. I think this explanation is correct. But I also think it describes the effect, not the actual cause. The cause is ACL's own security model, which is per volume based. Move/copy operations between different volumes being understood as a transference of privileges and changes within the same volume as being privilege agnostic. By default, naturally.
    – A Dwarf
    Jul 20, 2011 at 13:53
  • 1
    And logically, the permissions to a file are set at creation. Notice when you change permissions on a folder that you have to propagate the permissions to all child object. That's why Windows sometimes throws up a dialog box as it changes all the child objects if there are a lot.
    – surfasb
    Jul 20, 2011 at 18:39
  • 1
    @Mucker: Sorry, but your explanation is just plain wrong. Windows always stores the ACLs with the files, even if they're inherited. And from a file-system point of view, they always move with the file if the file is moved within the same volume. Depending on certain system settings, Windows Explorer will jump in and adjust the permissions after the move. But thats Explorer and has nothing to do with the file system. And worse: it depends on the Windows version and (as I already mentioned) certain system setting. See blogs.msdn.com/b/oldnewthing/archive/2006/08/24/717181.aspx
    – Paul Groke
    Mar 31, 2014 at 15:35

When you are moving files within the same volume you are traditionally rearranging your file system. Altering the file permissions at the level of the directory could lock you out of that file the moment the move operation is finished. This is undesirable if, for instance, you just accidentally moved a file to a system, or a folder with special ownership permissions or otherwise protected. There would be no way of correcting the mistake other than taking ownership of the file (if you have the privileges), or logging with a privileged account. Considering normal day-to-day operation of a computer, you could find you had no control over your filesystem.

This behavior is common among most (if not all) operating systems making use of ACL. It guarantees normal filesystem operations within a volume by users and applications alike.

Conversely, when moving files between volumes you are traditionally giving a file away for control by something or someone else. It makes sense, as you well realize, for the file to then incorporate the target folder permissions, which will give the target the necessary permissions to then rearrange its own filesystem as they see fit.

Naturally this isn't always desirable. For which reason move and copy operations can be defined with special permission inheritance rules. From the same article:

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

  • "This is undesirable if, for instance, you just accidentally moved a file to a system, or a folder with special ownership permissions or otherwise protected." - So you move a file e.g. to a folder with writeonly permissions and are still able to move the file back.. why isn't this desirable about different volumes?
    – VVS
    Jul 20, 2011 at 12:53
  • 1
    @VVS because ACL is a filesystem based security model. Each volume holds its own filesystem and consequently its own ACL table(s). From the perspective of ACL security, a different volume is the equivalent of a different "user". By moving a file to a different volume you are transferring control to that "user". But you are still given the option not to if indeed you so desire. It's just that the default behavior addresses ACL security concerns.
    – A Dwarf
    Jul 20, 2011 at 13:44

OK This is the real lowdown. First - are we talking about a single PC or a server? I assume we are talking about a Server. So....as a Wintel Admin of Company A you create a filesystem on a network drive on your new server. You base it on departments i.e. each department has a folder and each folder has its own unique ACL because of confidentiality issues, as is probably the norm - yes? Therefore, if you are going to move a file to another department's folder, why on earth would you NOT want it to inherit the perms of its new folder? What I mean is..why have a permissions-based filesystem if you are not going to use it? I can give you a real-life example where it is important for moved files/folders to always inherit their parent folder's ACL, just ask me.

Moving files within a volume or moving them from vol X to vol Y ... what IS the essential difference? You are moving the location of some files - across different volumes or not makes litle difference in a corporate environment as far as I can see. The real reason why one includes inheritance by default and the other doesn't has already been mentioned by Mucker - that is "efficiency". Dragging and dropping files within a volume just changes the Index entry - the files are not moved and their ACL info is left alone. Makes for a simple operation. When files are moved across volumes, however, the files and their ACLs have to be redefined, so doing it properly and including inheritance makes good sense as it does not incur an avoidable overhead.

I cannot understand why Microsoft don't address this issue. Would it be too difficult to include a dialog box as part of Explorer's drag n drop? Something like "You have moved files to a location with different access rights, do you wish to inherit the permissions of the new parent folder? Y or N?"

Regards, Stonegiant

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.