How to workaround the NTFS Move/Copy design flaw?

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

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.