ACL – Data moved on NTFS volume – Files disappeared / Access denied

Problem with moving files to NTFS volume:

– Files disappear after moving
– Denial of access when user is only authorized in the target-directory

Here, we provide you with a detailed solution including an example, screenshots and the ACL settings. 

After moving: files disappear / access denied

I guess many are already familiar with the problem, but not everyone knows yet why it happens:

After you moved files on a NTFS-volume from one folder structure to another, it happens that:

• Files “disappear“ or
• Persons who are only authorized in the target-directory cannot open the files (access denied)

Let’s take a look at that with the help of an example: 

 

Initial situation

• 2 User – User1 and User2
• 2 folders – Folder1 and Folder2. Both folders are on the same volume on a Windows Filer (CIFS-Share)
• 2 permission-groups – Group1 and Group2
• User1 is member of both groups
• User2 is only member of Group2
• Group1is authorized on Folder1. Group2 on Folder2
• Both respective groups grant Modify-permission on the folder
• The client is one of the following: Windows Server 2003, Windows XP, Windows Vista, Windows 7, Windows Server 2008 or Windows Server 2008 R2
• ABE is activated on the Filer! (basics on ABE,  detailed information at Technet)

 

 

 

Moving of file into new folder structure

 User1 created File1 and deposited it in Folder1.

User1 now wants to move File1 from Folder1 to Folder2, so that User2 can read it (User2 does not have reading rights in Folder1!).

First, let’s look at the ACL of File1:

As we can see, the file has the inherited permissions of Folder 1 (Group1). So far so good.

Now let’s move the file from Folder1 to Folder2:

 

View of the user and file-ACLs after moving

 

As we can see, User1 can see the file, but User2 cannot!

Looking at the ACL, we get this information:

The file still has the “old” permissions which it inherited from Folder1.
That explains why User2 cannot see the file – because ABE is activated, users can only see files they can at least read.
Would ABE be switched off, User2 could see the file but not open it!

Now we know why User2 cannot see it, but the explanation is still a little dissatisfying.

Why was the ACL not updated after moving?

The reason is nearly explained in the following kb-article:
http://support.microsoft.com/kb/310316

 

Solution and adjusting permissions

Because we are working on a Server2003, we set the Registry Key MoveSecurityAttributes in the LocalMachine Hive of our client (2003 Server):

 

Note: For Windows Vista, Windows 7, Windows Server 2008 und Windows Server 2008 R2 you will additionally need a Hotfix for the Key to work. You can find it here: http://support.microsoft.com/kb/2617058

The kb-article also explains that the user setting off the moving-process must have the right to change permissions in the target folder (Folder2).
We grant the user this permission:

Let’s try it one more time. Just to make sure everthing works right, we created a new File2.

We move File2 from Folder1 to Folder2.

Looking at the folder with User2, we see a familiar screen:

 

 

 Let’s look at the file as User1 and at the effective persmissions:

 

 Apparently, our user has the right „Change Permissions“! But why can’t we change the permissions of the file? The kb-article doesn’t say a word about that either.

The reason is that our users access via a share for which they only have “Change Permission“ (not FullControl):

This should basically be sufficient for all file-system-actions – after all, it is not easily visible what “FullControl” actually includes for a Share. But in fact, FullControl over a SharePermission also includes the ChangePermissions right.

Microsoft confirms that it is safe to grant users FullControl on Shares and limit permissions via NTFS:

http://technet.microsoft.com/en-us/library/cc754178.aspx

In general, if it comes to permissions of shares, the limiting permission is applied. In this case, the Share is limiting, because we are missing “Change permissions”.

 

Summing up, the solution to our problem consist of the following 3 points

1. Write MoveSecurityAttributes via policy on the client into the Local Machine Hive
2. Grant users the right “Change Permissions” in the Scope Files Only on the NTFS-volume
3. Set Share Permissions on FullControl

To prove that, we grant User1 FullControl on the Share (not on the NTFS-volume).

 

Afterwards, we move the same file from Folder1 to Folder2 – et voilá:

The permissions of the target folder were taken over correctly.