This post is more than 5 years old
56 Posts
0
7686
Changing File Ownership on SMB
I'm having a bit of an issue getting ownership to work. Little background: I have an app that archives files to an Isilon SMB share. But for the moment, I'm just experimenting with Windows explorer given that I can't get it to work there.
Two shares, 1 on Isilon and 1 on Windows Server 2012. I have 1 folder and 1 file in the folder in each share. Share permissions on both give THE domain administrator full control.
Folder ACL contains 2 allow ACEs, both full control; [DOMAIN]\Administrator and CREATOR OWNER
File ACL contains the 1 inherited ACE, full control; [DOMAIN]\Administrator
Both file and folder are owned by [DOMAIN]\Administrator
Logging into a separate Windows Server 2012 R2 instance as [DOMAIN]\Administrator, I mapped a network drive to each share. For either the folder or the file, if I try to change the owner to anything other than myself, on the Windows share, that succeeds, but on Isilon I get an ACCESS DENIED error (Details using Procmon: IRP_MJ_CREATE succeeds with WRITE_OWNER but IRP_MJ_SET_SECURITY fails with Information:Owner.)
I'd even tried changing the Isilon SMB permission for [DOMAIN]\Administrator to run as root and remapped the drive to no avail.
Here is the output from the shell on that file with [DOMAIN] substituted for our actual domain:
Isilon-7-2-1# ls -led Inventory\ Job\ SMB.Log
-rwx------ + 1 [DOMAIN]\admin [DOMAIN]\domai 522 Apr 6 15:50 Inventory Job SMB.Log
OWNER: user:[DOMAIN]\administrator
GROUP: group:[DOMAIN]\domain users
CONTROL:dacl_auto_inherited
0: user:[DOMAIN]\administrator allow inherited file_gen_all,inherited_ace
I'd rather not use THE domain administrator for some of these tests, but I figure if I get it to work there, then programmatically I can prove it out. Ultimately, the more typical use case will be to give our app some sort of administrative access to the share in whatever form and do the proper process elevation (SeTakeOwnership. SeRestore, etc.) But any help I can ge initially here will help greatly. Thank you so much.
crklosterman
450 Posts
0
April 10th, 2015 14:00
Adam,
What it sounds like you're running into here is the difference in the concept of 'bestowing permissions' between windows and Isilon.
On a windows server, you are given a privilege through the local security policy that permits you as a member of the local administrator's group to make an account you designate the owner of a given user or group, regardless of who owns the file currently. On Isilon, even with full control rights over a share and at the filesystem level, only the current owner can assign a new owner. This is most frequently discovered during migraitons of data to Isilon. The way to work around this is to, for the duration of a migration, give the service account doing the copying "run as root" access to a hidden administrative share at the top level of the data, perhaps the root path of your access zone. Make sure that you uncheck the "Apply Windows Default ACLs' box when creating the share through the Isilon WebUI, so that it does not modify permissions on data that may already exist under the path. Also do not create a share at /ifs. Only give this 1 account such access. Being treated as 'root' over SMB will permit the service account and whatever copy utility you are using to set the owner to match the source without an issue and all ACLs and SACLs. Does this make sense? It also allows you as an administrator the ability to lay down ACL permissions on directories that were perhaps created at the OneFS CLI and currently only have POSIX permissions, using Windows Explorer as you are probably accustomed to.
Hope it helps,
Chris Klosterman
Senior Solution Architect
EMC Isilon Offer & Enablement Team
chris.klosterman@emc.com
amarcionek
56 Posts
0
April 13th, 2015 07:00
Thanks Chris, the migration use case is precisely ours so this makes sense. I did as you said and was able to make ownership changes.
One final question, it looks like 'Apply Windows Default ACLs' is only available at share creation time. Can that setting be modified after share creation using the command line?
crklosterman
450 Posts
1
April 13th, 2015 09:00
Adam,
No that is a GUI only option, and not something you can change later from a share perspective, however you certainly can change the permissions later. So think of it this way; that check box, applies a pre-defined set of ntfs acl's to the folder in question. You can of course change those ACLs back to whatever you want. But that checkbox is the default, so be careful with it.
~Chris