How to workaround the NTFS Move/Copy design flaw?
Solution 1
My approach is to not use file/directory level file permissions; use file share level permissions, and set the whole server filesystem data drive to Everyone Full Control (which becomes moot).
Over the years (10+), I have found that NTFS permissions are more complex and leads to more errors. If the permissions are set wrong, or the inheritance gets broken, you expose data and its hard to find and see it. Plus, you are exposed to the move/copy problem as you say.
Places where you have to use directory/file level ACL's; I know of no other solution than health checking the thing on a regular basis.
Solution 2
Well it's not really a flaw. This rule for handling permissions when moving files has been in place since at least beta 2 of NT3.1 (though obviously not inheritance as that was only added with Windows 2000). It's about as well known as any feature of Windows can be. I have a lot of sympathy for your view, as there can be few of us that haven't been burned by this at one stage. But it's something that the sysadmin quickly learns.
JR
Solution 3
We've been using NTFS since NT 3.51 and though we've seen this "problem" (as has almost everyone) it hasn't caused us much trouble:
- We always tell people to copy files if they need to move them from one shared directory to another. "Hold down the CTRL key when dragging and make sure the little + is showing," is a common phrase.
- Our shared folders have a fairly simple structure, and the shared folders we create don't cross over between groups too often, so people are more likely to want to copy files in the first place.
- We see the problem mostly in our "common" space - folders where everyone can read/write, but those directories are mostly short-lived so the problem goes away when they're purged.
Solution 4
Workarounds I can think of:
- find some way of making the folders with different permissions be on different NTFS volumes
- Make a scheduled task (once an hour or once per day depending on the frequency of support requests) that runs through the folders and resets all the permissions to be the same as those from the top level. This is less than ideal, more so if the folders have many files in them, but is something that would keep the problem fixed if there is no good solution such as a server side registry fix. The command you will want to look at is called 'cacls' which you could then add to a batch file.
Disclaimer - I come from a unix background (and have implemented the last one to fix different permissions flaws - it feels icky, but does the job), so there may be a much better fix.
Solution 5
I use group policy / security policies / file system to keep track of complicated permissions. (NEVER use the "replace permissions" in the policy).
Schedule a CACLS to reset all permission during the night followed by a gpupdate /force to re-apply the permission from the policy. Works like a charm.
Related videos on Youtube
![ezakto](https://i.stack.imgur.com/cCXla.png?s=256&g=1)
ezakto
Updated on September 17, 2022Comments
-
ezakto almost 2 years
As anyone that has dealt with file server permissions is aware, NTFS has an interesting design feature/flaw known as the Move/Copy problem.
As explained in this MS KB article, the permissions for a folder or file do not automatically inherit from the parent if the folder is moved and the source and destination are on the same NTFS volume. The permissions are inherited if the folder is copied or if the source and destination are on different volumes.
Here is a quick example:
You have two shared folders on the same NTFS volume called "Technicians" and "Managers". The Technicians group has RW access to the Technicians folder and the Managers group has RW access to the "Managers" folder. If someone has access to both and they move a subfolder from the "Managers" folder to the "Technicians" folder, the folder that is moved is still only accessible to users in the "Managers" group. The "Technicians" group cannot access the subfolder even though it is under the "Technicians" folder and should be inheriting permissions from the top.
As you can imagine, this causes support calls, tickets, and wasted cycles on resolving these end user issues, not to mention the rats nest of permissions that you can end up with if users are often moving folders between different secured folders/area on the same volume.
The questions are:
What is the best way to workaround this NTFS design flaw and how are you handling it in your environment?
I know the linked KB article talks about some registry keys to change the default behavior of Windows Explorer but they are client-side and requires the users to have the ability to change permissions which I would think in most environments is a non-starter if you want to keep control over your file server permissions (and your sanity as a sysadmin).
-
Ward - Reinstate Monica about 15 yearsI know the Managers/Technicians example is just to illustrate the flaw, but in some cases that's the behaviour you'd want: if someone accidentally moves the folder from Managers to Technicians, you probably don't want the Technicians to be able to access it.
-
Michael Brown about 7 yearsThis really isn't a flaw, this is the way File permissions work. It has been documented since the release of NTFS. I cant believe that some people are recommending not using file permissions and only using share permission to control access. This goes against the very basics of security for a Microsoft File server. The reason that moving a folder / file on the same volume doesn't inherit is that the folder / file doesn't actually move on the disk, just the pointer we see changes.
-
-
Spence about 15 yearsI had an argument with Raymond Chen on his blog about this. Microsoft "sells" NTFS as having permission "inheritance", then backpedals when this particular chink in the armor is brought up. NTFS has permission inheritance at the time of file creation by placing explicit ACEs onto the files when they are created. I would argue that, so long as the documentation and marketing literature speaks about their inheritance system as though it's real-time either the documentation or the code is buggy. They should pick one and fix it.
-
Spence about 15 years+1 - The 1st answer that Mark gives is the best choice. It's a pain, but it's your best way to get around this stupid design decision in NTFS 5.
-
Spence about 15 yearsTo expand: This is a place where my SharePoint-using buddies would say "use SharePoint"! Likewise, my version-control-using-buddies and document-control-system-using-buddies would point to Subversion, Documentum, etc, and say "use that." This design choice in NTFS is a big huge wart, and it almost makes you wonder if Microsoft actually USES their own software when you have to fight with it in your own network. (It screams to me that Microsoft doesn't use their software in the same way that we do w/ our users, actually. Must be nice to have a company filled w/ "knowledge workers".)
-
John Rennie about 15 yearsWell it's a trade-off. If inheritance were real-time then every time you opened a file at the bottom of a deep tree the OS would have to run up the tree to find out what the effective permissions are. Of course the tradeoff is if you change the permissions at the top of a deep tree you have a loooong wait! Doesn't Active Directory use the same model?
-
ezakto about 15 yearsI'd agree that ideally we could separate out all the shared folders onto their own volumes, in practice this is unworkable for a large environment (thousands of shared folders). Also, without some funky junction point or symlink voodoo, this means losing the ability to have nested subfolders with different permissions on them.
-
ezakto about 15 yearsAD objects correctly inherit the new parent's permissions when moved between containers and I would argue that this is the expected "correct" behavior when moving file/folders in NTFS.
-
Spence about 15 years@renniej: AD does use true real-time inheritance. The Netware file system did it ages ago. NTFS could have done it, too, if Microsoft had implemented it. It's the "road not taken". What irks me is that Microsoft documentation re: NTFS and Explorer "plays" like the inheritance is real-time (i.e. lies). Tell it to us like it is, or fix the behaviour to jibe with the documentation!
-
Spence about 15 years@David: Moving the data across shares will result in a copy and delete. Moving data within a share will result in a move. If you make each shared folder the root of a permission hierarchy with no subfolders having more restrictive permission you'll alleviate the problem. Still ugly, though. (I do have a W2K3 server w/ 2200+ individual shared folders on it and I'm not seeing performance problems...)
-
Deb about 15 years@renniej As Evan Anderson said, Netware did this in 1990 back when they were king. The problem is fixable by creating another file-system index that tracks the 'visibility list'. Microsoft chose not to do that, but could conceivably shim one in for a future Windows Server release.
-
Spence about 15 yearsAre your users alive?
-
Maximus Minimus about 15 yearsSometimes I wonder...
-
JamesR almost 15 yearsI think I saw Raymond Chen say to the effect that it makes sense when you think of the whole ACL+ownership+quotas ball of wax.
-
SamB about 14 years@Even: Maybe none of them are in two groups!
-
Patrick de Ruijter over 13 years+1 for leading folks to the tool that solves this problem when maintaining files (along with many others); however, XCOPY has been depreciated: ROBOCOPY.EXE is its very capable successor.
-
colemik almost 12 yearsSorry for the nitpicking, but doesn't xcopy _copy_ the files (instead of _moving_ the files?) - it looks like the author has no issues with copying, he only has issues with _moving_. I may be wrong on this bc of my lack of experience, so please correct me if I'm wrong (i.e. do you use the 'del' command after using 'xcopy', so then the files are actually 'copied and deleted' != moved?)
-
Rich M over 4 yearsI've just tried this and unfortunately it hasn't worked. The permissions on the zip archive are different before I've even done anything with it. Inherited permissions remain but explicit ones are not created.
-
Rich M over 4 yearsPresumably this is only for Windows servers? As Group Policy has to be applied to domain objects, this couldn't be applied to non-Windows storage shares I would imagine?
-
Leidenfrosty almost 4 yearsThis is not only a bad approach (as share permissions are unreliable), but it's also against best practices which specify the allow minimally restrictive share permissions and utilize NTFS permissions to protect data. And for good reason. Share permissions don't protect data when the drive is disconnected from the OS or access locally.
-
Leidenfrosty almost 4 yearsEveryone keeps calling this a "problem", "flaw", or bug but this is not only expected behavior, it's the preferred behavior. It ensures that files and folder remain protected if accidentally dragged-and-dropped. It also helps prevent I/O overhead. When a file is moved on the same volume, the data is not moved but rather the file pointer is simply updated. Thus, moves are far more efficient and the ACL never changes. The pointer is updated to point the the file or folder with its original ACL intact.
-
JamesR almost 4 yearsAnd info on how share permissions are unreliable? I agree it goes against MS best practices, however I believe that is because MS wants you to be able to set permissions granular within the share; the shares I was using at the time did not require that. NTFS permissions don't protect you using another OS, and if you don't trust your sysadmins, well ...
-
JamesR over 2 yearsKinda game over if the drives are taken to another machine. Any admin can takeown and access the data.