3

In NTFS drives, the behavior used to be that, when a file was moved, it would retain the permissions of the original file, if the move was made to a folder on the same volume.

I know this by experience and it can be seen here: https://support.microsoft.com/en-us/kb/310316

But I was trying to show this behavior today to a colleague and it just didn't work. Every single time the file would simply have the permissions from the new folder associated to it.

I've tried in 3 different machines and it no longer works like that. When did it change? And no, the registry setting mentioned previously isn't set.

Any idea when this changed?

[Edit]

Just an example to make it more clear

Suppose I have these folders, in my C drive.

  • C:\Shared
    • \Working
    • \Final

And I have four groups: - Interns - Employees - Managers - Staff (that has the previous 3 as members).

Now, let's consider the permissions (simplified).

  • C:\Shared
    • Does not inherit
    • Explicitly allows Total Control to Admins
    • Explicitly allows Modify to Managers
  • C:\Shared\Working
    • Inherits from Shared
    • Explicitly allows Modify to Employees
  • C:\Shared\Final
    • Inherits from Shared
    • Explicitly allows Read to Staff

Now, let's supposed I have a file in the Working folder, called Bullshit.doc.

Previously, if the file was moved (cut/pasted) from the Working to the Final folder, it would retain the original permissions, i.e., Managers and Staff could Modify and Interns would have no permissions.

Now, when I try moving the Bullshit.doc, when moved, will simply inherit the permissions from the Final folder, i.e., it simply forgives that Interns shouldn't have access.

My question is: this changed, didn't it? Or I am going crazy? I'm 99% sure that it worked just like described in the KB.

I know I had problems similar to this in the past, when upper level users moved files between folders (with different set of permissions) and then complained that the interns couldn't read the files. I had to explain more than once that cut/paste wouldn't work, that they need to copy/paste/delete. It was back on Windows 2003 for sure, but I could be at least 2008 R2.

[Edit 2] Now with pictures!!!

Ok, so I decided to try and replicate. With the actual files and not simple examples. Here it is...

So this is the source folder. See all the implicit permissions and the one explicit permission. Some folder

Now, let's create a file in there. And check it permissions. Just a random document

Time to move the file to the destination. The original folder was just a temp folder. Let's check the destination folder permissions. Way less convoluted permissions

After moving the folder, let's check its permissions... WTAF!!!

Hum... not what I'd expect it. Even if it was just a file, from what I gathered in the KB above, it should keep the permissions. And that's how I remember it behaving.

But it seems it changed. And I can't find an official source of when it happened.

This makes makes me doubt my sanity.

  • Permission Inheritance can override this behavior. If the new folder inherits, the contents do not explicitly sever inheritance, and the source and destination containers do not inherit from the same ACL list, there will be differences in the resulting permissions. Also note that Windows Resource Protection (the mechanism that allows UAC to prompt in conjunction with permissions) requires more variation in permission ACLs throughout the filesystem (for instance, the program files and windows directories do not inherit from C, and user homes all have differant non-inherited permissions). – Frank Thomas Jan 28 '16 at 23:50
  • I added an example, to clarify. I really don't think that has anything to do with Permission inheritance. – Luiz Angelo Jan 29 '16 at 0:24
2
+50

NTFS is still evolving and changing. I believe that the changes to the handling of inherited permissions has first appeared in Vista and has further evolved in Windows 7. The registry setting in your link dates from XP, so as far as I know it is ignored in newer versions.

To understand what happens when one copies/moves a file, one must first understand the difference between implicit and explicit permissions.

Implicit permissions are inherited from the parent folder, so are stored with the parent folder. They are not stored with the children and therefore are not movable/copiable. In other words, these permissions only apply while the child is in its parent folder, because they come from the parent.

Explicit permissions are given manually to the folder/file and are stored in Access Control Lists (ACL) as NTFS attributes. They can be considered as belonging to the item and may in some cases be moved with it if the target file-system is also NTFS.

Some consequences of this NTFS architecture are :

  • When a folder/file is copied, new target entries are created in the NTFS tables of the target folder. Therefore the copied file will lose all explicit permissions, and will only inherit from its new parent folder.
  • When a file/folder is moved inside the same volume, its NTFS entry is moved, complete with all contained attributes and permissions. Therefore it will retain all explicit permissions, but will lose its old inherited permissions, gaining instead those of its new parent folder.
  • When a folder/file is moved between different volumes, the move is treated as a copy and will retain none of the original permissions. The only difference from copy is by the source being deleted when the copy is complete.
  • A file/folder that only has inherited permissions, has no permissions to move. Such an item will always inherit its permissions from the parent folder.
  • A folder/file may be marked as non-inheriting permissions from its parent. In that case, all its permissions are stored with it as ACLs, meaning as explicit permissions.

This goes against most established documentation, where it is usually claimed that when a folder/file is moved a inside the same volume, it will retain its original NTFS permissions, both implicit and explicit. This was maybe once true in older versions of Windows, but was verified by myself and by the poster as no longer being the case for implicit permissions in Windows 7 and Windows 10.

For an example of erroneously-documented move rules, see the article How file and folder permissions are handled while moving or copying files on Windows 2008 R2 and Windows 7. This article was the source of my discussion below with the poster, where we discovered together the true rules that govern copy and move in NTFS.

  • Hi Harry. I tried applying the rules to the example I gave, and it behaves differently. The rules stated above are exactly how I think it would behave. But when I try to reproduce it ends up ignoring the explicit permissions. Have you tried applying the rules to the example given? – Luiz Angelo Jan 31 '16 at 11:50
  • You need to define you case exactly. But as above, the fact that a file is in a folder does not mean that the folder permissions will move with it - only permissions granted explicitly to the file itself, or granted to the folder but with propagation to the children (propagation only works for existing files and new ones will only inherit). – harrymc Jan 31 '16 at 12:14
  • I thought the example case was pretty clear. Anyhow, I tried with folders and explicit permissions. When moved, the folder didn't retain the original permissions. I guess I'll edit the question later with pictures and examples. – Luiz Angelo Jan 31 '16 at 12:33
  • Is your case a move on same volume? And which Windows version? Yes - some examples of non-retained permissions would be useful. – harrymc Jan 31 '16 at 16:24
  • And are you moving files or a folder? – harrymc Jan 31 '16 at 21:35
1

There is an additional important detail to add to harrymc's excellent and comprehensive explanation, and this detail ends up causing split behaviour, where a file move sometimes behaves in the 2003-style and sometimes in the 2008-style.

The manner in which NTFS intra-volume moves was updated in 2008/Vista and above is not a complete overhaul, but just adding a second step in the background.

Step 1) MFT is updated; the file is moved and retains original permissions
(Just like in 2003/XP and earlier. Moves on those OSes stop at this step.)

Step 2) ACLs are updated to drop the original parent folder's inherited permissions and apply the new parent folder's inherited permissions.
(This is the additional step that 2008/Vista added so files will have the target folder's permissions.)

However, if the user who is performing the move has Modify rights and does not explicitly have the Change Permissions right, step 2 will fail (but not tell you), and you will end up with the old-school behavior so it seems like things are back in 2003 again.

In this same scenario, if someone copies the file and then deletes the original (the same way the file system handles a move between volumes), everything works the way you would expect it to.

There isn't any graceful solution - you either give users Change Permissions rights so Step 2 can succeed, or any files moved between different-permission folders on the same file server volume will retain their original permissions until they are forcibly re-propagated.

  • This is an addition to an existing answer and not an answer in itself. Please post it as a comment. – wp78de Sep 12 '17 at 22:59

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.