Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

share|improve this question
1  
I 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. –  Ward Jun 25 '09 at 18:12

7 Answers 7

up vote 11 down vote accepted

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.

share|improve this answer

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

share|improve this answer
5  
I 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. –  Evan Anderson Jun 25 '09 at 17:19
1  
Well 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? –  John Rennie Jun 25 '09 at 17:34
    
AD 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. –  David Archer Jun 25 '09 at 17:58
2  
@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! –  Evan Anderson Jun 25 '09 at 18:02
    
@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. –  sysadmin1138 Jun 25 '09 at 18:26

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.
share|improve this answer

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.

share|improve this answer
    
+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. –  Evan Anderson Jun 25 '09 at 17:21
    
To 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".) –  Evan Anderson Jun 25 '09 at 17:24
1  
I'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. –  David Archer Jun 25 '09 at 17:57
1  
@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...) –  Evan Anderson Jun 25 '09 at 18:05

When moving as an admin I use xcopy /s/e/c/h/r/k/y - everything aside from file ownership and ACL, meaning that ACL inheritance automatically kicks in. Never really had to deal with a situation where a user moved stuff though.

share|improve this answer
    
Are your users alive? –  Evan Anderson Jun 26 '09 at 4:02
2  
Sometimes I wonder... –  Darth Satan Jun 26 '09 at 7:58
    
@Even: Maybe none of them are in two groups! –  SamB May 9 '10 at 17:20
    
+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. –  jnaab Mar 22 '11 at 14:13
    
Sorry 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?) –  colemik Jul 5 '12 at 15:05

A very simple workaround is to just zip the files and uncompress it to the destination directory.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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