NFS share permission denied

Hello bhuvankumar,

Thank you for your question! Can we get some additional information about your environment?

1. Do you have the SMB rollup patch installed on your version of OneFS? We can get this information with:
   1. # isi pkg info
2. Can we get the full permission set on these directories?
   1. # ls -lead /ifs/
   2. # ls -lead /ifs/ /
3. What authentication method do your users use? Are the Unix and Windows users all using AD? Or do you have another auth provider in your environment?

Please let us know as soon as you are able and we will take a look at this for you!

Hi Katie,

1. no packages are installed

2. main directory

ls -lead /ifs/GFR/testtext/vol/

drwxrwxr-x +  144 root  wheel  3494 Jul 23 21:23 /ifs/GFR/testtext/vol/

OWNER: user:root

GROUP: group:wheel

CONTROL:dacl_auto_inherited,dacl_protected

0: group:Administrators allow dir_gen_all,object_inherit,container_inherit

1: creator_owner allow dir_gen_all,object_inherit,container_inherit,inherit_only

2: everyone allow dir_gen_read,dir_gen_execute

3: group:Users allow dir_gen_read,dir_gen_execute,object_inherit,container_inherit

4: group:Users allow std_synchronize,add_file,add_subdir,container_inherit

Afftected complete path file end of the file from main sub folder till the end of file, below security group in bold was applied from SMB share and later to rectify the issue we have applied user (otxadm) and group (otxsys) through chmod -R +a command on the path

ls -lead /ifs/GFR/testtext/vol/BV_004_1E/00/54/66/000F4CA8

drwxrwx--- +  2 otxadm  otxsys  40 Sep 19  2011 /ifs/GFR/testtext/vol/BV_004_1E/00/54/66/000F4CA8

OWNER: user:otxadm

GROUP: group:otxsys

0: group:NA\000-212_opentext_admins allow dir_gen_all,object_inherit,container_inherit

1: user:otxadm allow dir_gen_read,dir_gen_write,dir_gen_execute,std_write_dac,delete_child

2: group:otxsys allow std_read_dac,std_synchronize,dir_read_attr

3: user:otxadm allow inherited dir_gen_read,dir_gen_write,dir_gen_execute,std_write_dac,delete_child,object_inherit,container_inherit,inherited_ace

4: group:otxsys allow inherited dir_gen_read,dir_gen_write,dir_gen_execute,std_write_dac,delete_child,object_inherit,container_inherit,inherited_ace

3. Authentication is on unix (AIX) hosts with user "otxadm"

We got a request to have a copy of three directories from this path to another path in the same cluster so that user can work on some test reports. Those three directories already have individual NFS paths and we have created one SMB path to top level one /ifs/GFR/testtext/vol/ and provided access to one security group, after 30mins issue started with permission denied at unix hosts for NFS shares even though still the SMB permissions were applying on top level directory

Hello,

Based on that information, this looks like an issue with the inherited permissions applying from the SMB share. Can you please provide us with the share configuration?

We have deleted the SMB share on the same day when issue started, We just configured by giving SMB share name, path (/ifs/GFR/testtext/vol/) and full permission to group NA\000-212_opentext_admins, once the SMb share permission started applying on one by one sub directories i could see a "+" adding as per below output

drwxrwxr-x +   2 otxadm  otxsys         51 Jun  3  2013 BV_004_1E

Whether or not an SMB share is present isn't your problem here.  The fact that you see a '+' sign when doing an ls -l or an ls -ld from the Isilon cluster itself is trying to tell you that the POSIX bits are synthetically generated based upon an ACL.  Add a -e and you'll see the ACL.  Add a -n and you'll see the numeric representation of that ACL with SIDs and UIDs.  Isilon enhanced the ls command to help show this information.  We also enhanced the chmod syntax at the Isilon CLI to interact with ACLs.  Do a 'man chmod' on your Isilon cluster an look at the +a / -a syntax options.  If this data is going to be NFS-only then you will want to strip off the ACL that exists on it.  This can be done with 'chmod -R -D /ifs/pathtofolder'.  Please note that this is recursive.  Also be aware that if this path is 10 levels deep in a tree that ACLs above this path if changed may still inherit down and affect this path.

It's important to keep in mind that if an ACL exists on a directory that the default behavior when you issue a chmod from an NFS client is to try and merge the chmod options into an ACE in the ACL, not replace the ACL.  Ultimately the POSIX permissions you see aren't authoritative, we actually check the ACL even over NFSv3, despite the fact that you can't see or change the ACL over NFSv3.

Be careful when you see some of the more advanced ACL options in the WebUI,because those settings are global to the whole cluster, though ultimately we can usually find a combination of them that meets most people's business needs.

And ensure that you understand that there is no industry standard for how to gel together NTFS ACLs and POSIX permission bits, each NAS platform does it a little bit differently.  We happen to think that ours is the most consistent end to end, but I guess I'm a bit biased.

~Chris Klosterman

chris.klosterman@emc.com

Advisory Solution Architect

EMC Isilon Offer & Enablement team