Hello,

We're running Windows 2008 R2 as a file server which is also acting as a member domain controller, the clients are a mix of Windows XP and Windows 7.

Users are cutting scans from their secured "scans" folder and pasting them into various folders/directories with various security groups/rights.

When users cut and paste the files are retaining the rights from their "scans" folder which then prevents others users from viewing these documents. I understand how a file server handles this i.e. copy/paste rights are inherited cut/paste rights are not; however, to the end user this makes ZERO sense and trying to explain makes even less sense.

How do we make this seemless for end users copy/paste and cut/paste always get inherited privleges?

Thank you in advance,
Brian

Hi Brian,

As you said, this is the designed behaviour.

Copy inherits permissions from parent folder destination.

Move inherits permissions from the parent folder destination if the move is between two volumes. (So, same as copy behavior.)

Move preserves permissions from the source if the source and destination are on the same volume. This is what happened in your case.

In addition, I noticed that if "include privlege from parent object" option is not select, it works like the third rule, or it will work as the second.

To workaround this, you may suggest clients to:

a. Create share folder on another volume (so meet rule 2).

Or

b. Copy scan file instead of cut, with clear scan folder instead of directly cut and paste.

If there is anything further we can help please just let us know.

Can these behavour be modified via the server registry? See below, per Article ID: 310316

1. Click Start, click Run, type regedit, and then press ENTER.
2. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer
3. On the Edit menu, click Add Value, and then add the following registry value:
   
   Value name: MoveSecurityAttributes
   Data type: DWORD
   Value data: 0
4. Exit Registry Editor.
5. Make sure that the user account that is used to move the object has the Change Permissions permission set. If the permission is not set, grant the Change Permissions permission to the user account.

OK, I have tested this issue further.

I have a Windows 7 x64 client and a 2008 R2 DC/file server.

• I did a copy/paste from a secured user folder to a shared folder with different security rights, the copy/pasted file inherited rights of the new location (GOOD.)
• I did a cut/paste from a secured user folder to a shared folder with different security rights, the cut/pasted file inherited rights of the new location (GOOD.)
• I then built a new virtual machine running Windows XP and ran the above tests, with the exact same results (GOOD.)

The issue now is I have some XP clients in the field that a cut/paste are NOT yielding the same results against the same server I did my tests against. What can be the cause of that?

In order to use MoveSecurityAttributes as you were able in Windows XP/Windows Server 2003, you will need to install the following hotfix:

http://support.microsoft.com/kb/2617058

Hope this helps!

This posting is provided "AS IS" with no warranties, and confers no rights

• Edited by Alexander SklarMicrosoft employee Friday, July 13, 2012 2:23 PM typo
• Proposed as answer by Alexander SklarMicrosoft employee Friday, July 13, 2012 2:23 PM

Hello

we got 2008 R2 File Server and Windows 7 x64 clients. NTFS Permissions on the department folders are either read&exe or modify.
Since i can remember Users are calling me, because they think files or folders are deleted, but they are actually moved or they can't access, because someone moved cross over the department folders.
It really doesn't matter how often you teach users to avoid this, but they won't learn it.

Now I was wondering, if you could help me find a way to deny the user the ability to move files or folders.
Thing is, that somehow "moving" is copy/delete function in source and destination location, what makes it difficult.
I already tried with Hotfix and the regkey i found here to "at least" configure the "move"-action into a simple "copy"-action, but this also didn't work.
Also i tried changing the modify permission in advanced area to deny "delete subfolders and files", but the user was still able to delete files.

Maybe i'm doing something wrong, so I really hope you can help me implementing one of this solutions. 
Thanks.

Hi Steven,

In that case you can add a Deny clause for "Delete" (not just "Delete subfolders and files") for that group of users. This will prevent them from moving the file and force them to learn to copy it instead.

My two cents: note however that if you don't trust your users to do the right thing (through education, etc.) you should also be worrying about them replacing the contents of the files with bogus data as there is nothing preventing them from doing so. Eventually you either end up with a really locked down environment (e.g. read only shares) that is difficult to use, or you invest more in user education :)

Hope this helps!

 

This posting is provided "AS IS" with no warranties, and confers no rights

Thanks, but now they can't delete nor rename. they always have to rename, we all know that.
However, if i can't deny the move, then isn't it possible to change the move job into a copy job.
I thought that was the thing they tried to accomplish here:
http://support.microsoft.com/kb/310316
http://support.microsoft.com/kb/2617058

what else could i try?

thanks.

Yeah, I am responding to an old post.

"Delete subfolders and files" guarantees you the ability to delete sub-files/folders even if you do not have the delete permission.

It is a complicated question/thread.

You can use an explicit "deny" on "this folder only" for "delete".  What this nets you is if a person tries to take direct action on that folder, it will fail.  However, if they take action on one of the folders ancestors (higher in the folder tree), you will get varied results depending on the copy/move rules configured on the computer taking the action.  By default, a move within the same volume on an ancestor will still work because the action is being taken on the folders ancestor, and not the actual file/folder the deny is set on.  If the move action is taken on an ancestor  between volumes, it will move some subset of files until the move operation actually tries to move the folder configured with a deny, and then an error will be thrown when the operation attempts to delete the original file after it is copied.  This may result in some of the content being moved to the new location, and some of the content being left in the source location.  In short, you can make some configuration choices that will help, for example you can configure a delete inhibit on a root level folders, but protecting folders further down the folder tree is a choice you will need to evaluate because the net result can be confusing both to the end user and the administrator.

BUT... if the volume grants "Delete subfolders and files" to the administrators, which is part of the default rights for "Full Control", then when an administrator attempts a move between volumes, it will work because the the volume level rights guaranteed the delete operation, and thus the move is successful.  In essence, even root level folders are subject to accidental moves by a quick clicking administrator.

In a similar manner, a move between volumes will succeed if the person performing the operation has "full control" or "delete subfolders and files" on an ancestor.  This is one of the reasons not to grant "Full Control" when assigning NTFS rights to end users.

To complicate this even further, you may see varying results from NAS units and other "Simulated" Windows servers if they interpret the owner of a folder as an implicit "full control".

Like I said, the question and answer is more complicated than it appears.  As with any answer posted on the Internet, the previous statements may be inaccurate or completely false, so test test test.

• Edited by IdahoAnalyst 1 hour 43 minutes ago