What will happen to the original NTFS permissions Once the folder has been moved?
Views:1,222Visibility:PublicVotes:0Category:data-ontap-7Specialty:7dotLast Updated: Show
Applies to
AnswerWhen the same directory is cut / pasted the access rights are not properly inherited. This behavior of permissions is EXPECTED in NTFS volumes due to the design of NTFS Access Control List (ACL)s. According to Microsoft's KB article: How permissions are handled when you copy and move files and folders, by default an object inherits permissions from its parent object, either at the time of creation or when it is copied or moved to its parent folder. The only exception to this rule occurs when you move an object to a different folder on the same volume. In this case, the original permissions are retained. NetApp's SMB server will act like a modern Windows SMB server with regards to inheritance. Test the same operation from the same client against a Windows SMB server configured in the same manner. If everything is identical, take packet traces against the "working" SMB server and against the NetApp SMB which is not behaving as expected. Record the following information:
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). I have explained this in a blog post http://think-like-a-computer.com/2011/07/24/moving-files-on-the-same-ntfs-volume-does-inherit-permissions/ but it is also explained below. When a file is copied, it has to create a brand new file and assign it a new set of permissions, so it gets the permissions from the parent folder as you know. When a file is moved to another volume, what actually happens is that it is copied to the new volume and the old file is deleted. So the same process is repeated as above as it is a new file again and needs permissions set. When the file is moved within the same volume, nothing really happens (at the disk level). It just changes the logical path location of the file. The actual data and physical file on the disk hasn't been touched or changed. Ever noticed when you move a 5GB file to another folder on the same drive, it is done almost instantly? This is why, because it actually hasn't moved but the pointer to where the file logically exists has changed. As it was not modified in any way, the permissions don't change also. This is the reason for this behaviour. Edit: Something I forgot to mention... The MS article isn't entirely accurate. MS quote:
The above quote only applies to objects that have been given EXPLICITLY defined sec permissions (turn inheritance off). As mentioned in my comments, it is all about keeping the ACL entries as efficient as possible. Consider the following example: To keep the explanation simple, let's say you have a folder set to allow users modify rights only. Below this, there're thousands of files and none of them have explicit permissions set. It isn't very efficient to create ACLs for each file as they are exactly the same perms so it sets ONE ACL entry for the folder. This next bit is very IMPORTANT to understand; the files themselves have NO ACL PERMS. So when you move any of these file into a new folder in the same volume, MS claims the perms move with it (as above quote). Ask yourself this....how? There were no perms on the file in the first place to move across. This is actually incorrect and I just tested it now to confirm it. Let's say the destination folder you are moving the file to has perms to allow the everyone group modify rights only. Well since the file has no ACL directly, it inherits the ACL of the parent folder. This means the perms have changed from users modify (old folder) to everyone modify (new folder). Notice the difference?? This time around, moving a file to another folder in the same volume actually has changed the perms, something MS says it doesn't do. Have I just found a mistake in MS documentation since 2000 lol?? Now look at the same scenario when using explicit permissions. If you set explicit permissions on a file within this folder (inheritance turned off) which, for example, denies users read access, it now creates A NEW ACL entry specifically for this file. Now when you move the file to a new location, it has an ACL entry directly related to it. In this case, moving a file to a new location in the same volume RETAINS its permissions (as MS claims)! What happens when you move a file with NTFS permissions to a different NTFS volume?What happens when you move a file with NTFS permissions to a different NTFS volume? The file inherits the permissions of the parent folder to which it is moved.
What happens to the share permissions on the folder after the move?It inherits new permissions from the destination folder, in addition to other, explicitly set, permissions. Users no longer see the moved files or folders in the shared folder.
What happens to permissions if I move a file from NTFS to fat32?Copying Files and Folders
When copying a folder or file between different NTFS partitions, the copy of the folder or file inherits the destination folder permissions. When copying folders or files to non NTFS partitions such as File Allocation Table (FAT), the files or folders will lose their all NTFS permissions.
When you copy or move NTFS files the permissions that have been set for those files might change?If you move a file from one folder to another folder on the same NTFS volume, the file will retain the original NTFS permissions. If you move a file from one folder to another folder between different NTFS volumes, the file is treated as a copy and will have the same permissions as the destination folder.
|
