33

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

David Archer
  • 599
  • 1
  • 6
  • 16
  • 2
    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 - Reinstate Monica Jun 25 '09 at 18:12
  • 2
    This 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. – Michael Brown Apr 04 '17 at 08:24

8 Answers8

13

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.

JamesR
  • 1,061
  • 5
  • 6
  • This 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. – Nilpo Aug 18 '20 at 01:47
  • And 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 Aug 19 '20 at 11:56
  • Kinda game over if the drives are taken to another machine. Any admin can takeown and access the data. – JamesR Feb 23 '22 at 13:50
10

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

John Rennie
  • 7,756
  • 1
  • 22
  • 34
  • 8
    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
  • 3
    @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
  • I 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. – JamesR Jul 29 '09 at 17:10
  • Everyone 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. – Nilpo Aug 18 '20 at 01:50
6

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.
Ward - Reinstate Monica
  • 12,788
  • 28
  • 44
  • 59
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.

Mark
  • 2,846
  • 19
  • 13
  • +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
3

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.

Maximus Minimus
  • 8,937
  • 1
  • 22
  • 36
  • 2
    Are your users alive? – Evan Anderson Jun 26 '09 at 04:02
  • 4
    Sometimes I wonder... – Maximus Minimus Jun 26 '09 at 07:58
  • @Even: Maybe none of them are in two groups! – SamB May 09 '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
  • 2
    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 05 '12 at 15:05
3

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.

Alexandru Nica
  • 39
  • 1
  • Presumably 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? – Rich M Oct 15 '19 at 10:26
2

Since Windows 7 (or maybe Windows Vista), the permissions for a folder or file DO inherit from the parent if the folder is moved and the source and destination are on the same NTFS volume - if a file or folder is being copied via Explorer. In an earlier OS, you can use Far manager - it allows to enable permissions inheritance from the destination (along with tons of other features). Though Far may seem not friendly for a general user.

GCRaistlin
  • 106
  • 8
0

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

Bob
  • 2,917
  • 5
  • 28
  • 32
  • I'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 Oct 15 '19 at 07:42