chmod command w/ object_inherit,container_inherit not setting inheritance

Hello lpphiggp,

What is your current Onefs version?  Here are the links to a couple of kb’s that maybe of assistance.

https://dell.to/3QIdZZL

https://dell.to/3yfW1H9

Hi Sam,

We're a bit outdated:  8.1.2    an update is pending

Hello lpphiggp,

Are you needing to change SMB or NFS share permission’s?

Hi Sam.  SMB. 

Hello lpphiggp,

After you modify the ACL did you run the PermissionRepair job?  This is located on page 144 of this link.

https://dell.to/3blkrWv

Hi Sam,

Never occurred to me.  I thought that was to repair upper level permissions /ifs in a really bad scenario.
Since I've never run it I wasn't aware the other options would only then appear, such as which directories to choose. I'll give that a shot and update the page, thanks.  Might not be for a few days now however, I had to move on to other projects in the interim.

Just one question as to how to apply:  I assume I would set the root of the share as the Template File or Directory, and then the same again for the Path,  since I need the inheritance to flow on down from the root of the share to it's subfolders?

 Hello lpphiggp,

that is correct.

That didn't give expected results: 

First I ran:  "chmod +a user DSP\\testuser allow dir_gen_all,object_inherit,container_inherit /ifs/Isilon/smb/test"

Then checked the share, and sure enough, testusers appeared in the root of the test share with full control, but the inheritance didn't work, the user does not appear in the 2 subfolders whatsoever.

I set both paths the same  (/ifs/Isilon/smb/test) and ran the permission job.  
But instead of seeing testuser as inherited, it gave him rights to everything explicitly.   So it's more like a copy permission.  I'm just trying to get inheritance to work the way it should, so maybe I also have to go to ACL policy settings and enable the below setting in addition to the permissions repair?  (Neither work by themselves)
Thanks

ACLs Created On Directories By the chmod Command

Hello lpphiggp,

It is best to open a support case for this so that we can pull some logs to see what is going on.

Hi Sam,

Understood.  It is an odd one. 
Thank you for your assist!

@lpphiggp​ Hello, just wondering if you got a resolution to this, and if so, what it was? I'm trying to understand how to properly set permissions via OneFS CLI at the top level of an existing share and have them properly inherited by all child objects, as you described in your scenario.

Currently I'm seeing the same behavior you were (on a much newer OneFS - v9.7.1.0), although one extra thing I noticed is it seems like the permissions are properly inherited by all newly-created objects under the top-level folder. It's just they aren't inherited by any existing objects (which is a big problem of course, in our case we have a share with literally millions of files under it, we need it to be properly inherited). The other thing I noticed is the "make ACLs applied via chmod inheritable" setting (in the SMB policy settings) did not seem to have any effect (didn't change the behavior of inheritance regardless).

Any insight you could provide would be much appreciated, thanks!

@dwillis77 

I don't clearly recall how it turned out now, to be honest, this was quite a while ago.
It certainly seems more complex than regular MS shares though.
In general, what I do is retrace all the steps:
1. Using OneFS webadmin, under Protocols, Windows sharing, smb zone, for each share,  make sure Everyone has full rights to the share, then control permissions strictly via NTFS permissions. 
2. Enable Access Based Enumeration under Advanced settings for the share
3. In Windows, under the share's security properties, I usually use the Advanced dialog, it seems to work better. 
4. Don't forget to check the "Replace all child object permission entries  ..from this object"
 at the root of the share.

Also, check that you don't have any missing SPNs.  They might not all be necessary but they don't hurt either. You have to check and fix that via CLI, so you have to SSH into the Isilon/PowerScale.
# isi auth ads spn list <your domain>
# isi auth ads spn check <your domain>
# isi auth ads spn fix <your domain> --user administrator --noremove

Then run the check again. 

Hope that helps, that's really all I got. 

@lpphiggp​ No worries, I know it was an old thread but thanks for your reply. The process you mentioned definitely works through the UI, and good point about the SPNs - we do also have those registered. I was just looking for a way to set the same via the CLI if necessary, for one just in case the NTFS ACLs get messed up somehow (although I know those can also be fixed via the Windows UI if you connect as a user that has "run as root" rights on the share as defined in the OneFS web UI), but also because setting the permissions via the Windows UI on a share with so many files can take hours to complete.

In case anyone else comes across this thread. There were two main roadblocks I had to get past to set SMB ACLs from the OneFS CLI successfully (and have them inherited by child objects). One was that if your shares are in a non-default zone and your AD provider is not linked to the System zone, your AD users will not be resolvable in the System zone. So any native Linux commands like chown, chmod, ls, etc. must be run in the context of the custom zone to be successful, which can be done with "isi_run -z# <command>" where # is the zone ID and <command> is the Linux command to run. The other was getting the child objects to inherit successfully. The only way I found to do this so far was using the "chmod +ai" command which will set permissions and mark them as "inherited". So if you do this on all child objects under the object you want permissions to be inherited from, this will (seemingly) achieve the result we want. But the part that's a little tricky is the permission flags needed are different for files and folders, so we must make use of the "find" command and run three commands total - one on the top-level folder to set the permissions, one against all child file objects to set the appropriate file permissions with "inherited" flag set and one against all child directory objects to do the same but with directory permissions.

Here's an example if the top-level folder was /ifs/CustomZone/ShareA/testFolderA

isi_run -z2 chmod +a user "DOMAIN\user" allow dir_gen_read,dir_gen_write,dir_gen_execute,std_delete,object_inherit,container_inherit /ifs/CustomZone/ShareA/testFolderA
find /ifs/CustomZone/ShareA/testFolderA -type f -exec isi_run -z2 chmod +ai user "DOMAIN\user" allow file_gen_read,file_gen_write,file_gen_execute,std_delete '{}' +
find /ifs/CustomZone/ShareA/testFolderA/* -type d -exec isi_run -z2 chmod +ai user "DOMAIN\user" allow dir_gen_read,dir_gen_write,dir_gen_execute,std_delete,object_inherit,container_inherit '{}' +

Hopefully this could be of help to someone in a similar situation.

Best regards

@dwillis77​   Great info!