Of course it should go without saying to not test this in production. The setting I suggested may not also meet your workflow needs, and is cluster-wide, hence the need to test in a non-production environment first.
As to your multiprotocol issue, what you'll find is that of course the default behavior of POSIX permissions and ACLs are very different. This is specifically related to inheritance. Once a top level folder has an ACL, everything underneath it will inherit that ACL. In POSIX, this is different per distribution, but in general without a sticky bit POSIX does not inherit. To manage this disparity, your best bet (in general) is to either separate the folders that need to be NFS only from those that need to be SMB only. That's the cleanest approach. But to go multiprotocol, ACLs aren't supported over NFSv3, however Isilon will still check them, so you could add Root and Wheel back to the ACL for instance. But also be careful to set ACLs created on directories by UNIX chmod:
To:
Make them inheritable.
The reason for this is that you as an NFS user might write a file, and if the POSIX permissions on the top-level folder in an ACL aren't inherited down, you might not have access to write the file that you just created.
Thank you for the reply. I wish I would have seen the link you attached before we ever created a directory on our Isilon. We created all of our agency folders in the root of ifs when in hindsight we should have created a folder similar to “ClusterA” in your example since we do in fact replicate to another location. Which in turn replicates back to this location. Fortuanetly we have not started putting anything other than replicated data on our remote side so I can at least create a “ClusterB” on that side before we do start using it.
As for my initial issue of how to handle the NFS exports I think I will create a second folder for each agency in /ifs that will be just for NFS shares. i.e ifs/personnel and ifs/personelnfs. Fortunatley we do not have very many created so far so it shouldn’t not be too painful reconfiguring them. I assuming I can just created the new directory and present it as an NFS Export and then just copy the data to the new location and mount the new export. Does this sound correct?
Thank you for the reply. I wish I would have seen the link you attached before we ever created a directory on our Isilon. We created all of our agency folders in the root of ifs when in hindsight we should have created a folder similar to “ClusterA” in your example since we do in fact replicate to another location. Which in turn replicates back to this location. Fortuanetly we have not started putting anything other than replicated data on our remote side so I can at least create a “ClusterB” on that side before we do start using it.
As for my initial issue of how to handle the NFS exports I think I will create a second folder for each agency in /ifs that will be just for NFS shares. i.e ifs/personnel and ifs/personelnfs. Fortunatley we do not have very many created so far so it shouldn’t not be too painful reconfiguring them. I assuming I can just created the new directory and present it as an NFS Export and then just copy the data to the new location and mount the new export. Does this sound correct?
use chmod +ai from the cluster CLI. Isilon has enhanced chmod to be able to modify ACLs, so for all the options, look at 'man chmod'. Also to look at the existing ACLs, do an ls -le /path.
If you are still running and older version of OneFS you can use setfacl, but it is depreciated. In new versions you need to use chmod.
"chmod +a" will add an ACL to the top of the local allow and local deny lists.
"chmod +ai" will add inherited entires of the ACL
The correct form for an ACL order is:
local deny
local allow
inherited deny
inherited allow
If, for whatever reason, you need a specific order of ACLs you van use "chmod +a#" or "chmod +ai#" for inserting at a specific location.
To remove an ACL you can "chmod -a". If you need to remove all ACLs you can use a brute force option, "chmod -N or chmod -RN for recursive" which will delete all ACLs and write a null ACL.
I also have a script which will clone permissions (including ACLs) from a source file onto a target which you can find here. You can also use a PermissionRepairJob to do the same thing, but may be overkill if you need just a few files.
Mark, I use Komodo a Perl IDE when working with Perl. It suggested a few syntax tweaks to your script, so I've made them, and would like to send you the revised copy, if you want to reach out to me directly with your contact info. (nothing really major).
dynamox
9 Legend
•
20.4K Posts
0
April 3rd, 2014 11:00
did you also consider incorporating ABE (access based enumeration) and not create many shares for the same agency ?
dynamox
9 Legend
•
20.4K Posts
0
April 3rd, 2014 11:00
when we first purchased our cluster i went with this configuration:
/ifs/data/cifs/department1
/ifs/data/cifs/department2
/ifs/data/cifs/department2
/ifs/data/nfs/department1
/ifs/data/nfs/department2
/ifs/data/nfs/department2
i was concerned if i went with something like this:
/ifs/data/department1
/cifs
/nfs
and gave department access at "department1" level, they would try to "fix" cifs permissions and would break NFS access.
crklosterman
450 Posts
0
April 3rd, 2014 11:00
Of course it should go without saying to not test this in production. The setting I suggested may not also meet your workflow needs, and is cluster-wide, hence the need to test in a non-production environment first.
dynamox
9 Legend
•
20.4K Posts
0
April 3rd, 2014 11:00
Chris,
how do you add root and wheel to ACLs without overwriting ACLs ?
crklosterman
450 Posts
0
April 3rd, 2014 11:00
Ryan,
A good thread is available here on how best to layout a filesystem:
Isilon folder layout - /ifs/data usage
As to your multiprotocol issue, what you'll find is that of course the default behavior of POSIX permissions and ACLs are very different. This is specifically related to inheritance. Once a top level folder has an ACL, everything underneath it will inherit that ACL. In POSIX, this is different per distribution, but in general without a sticky bit POSIX does not inherit. To manage this disparity, your best bet (in general) is to either separate the folders that need to be NFS only from those that need to be SMB only. That's the cleanest approach. But to go multiprotocol, ACLs aren't supported over NFSv3, however Isilon will still check them, so you could add Root and Wheel back to the ACL for instance. But also be careful to set ACLs created on directories by UNIX chmod:
To:
Make them inheritable.
The reason for this is that you as an NFS user might write a file, and if the POSIX permissions on the top-level folder in an ACL aren't inherited down, you might not have access to write the file that you just created.
~Chris Klosterman
Senior Solution Architect
EMC Isilon Offer & Enablement Team
chris.klosterman@emc.com
ryan_meyers
1 Rookie
•
17 Posts
0
April 3rd, 2014 12:00
Thank you for the reply. I wish I would have seen the link you attached before we ever created a directory on our Isilon. We created all of our agency folders in the root of ifs when in hindsight we should have created a folder similar to “ClusterA” in your example since we do in fact replicate to another location. Which in turn replicates back to this location. Fortuanetly we have not started putting anything other than replicated data on our remote side so I can at least create a “ClusterB” on that side before we do start using it.
As for my initial issue of how to handle the NFS exports I think I will create a second folder for each agency in /ifs that will be just for NFS shares. i.e ifs/personnel and ifs/personelnfs. Fortunatley we do not have very many created so far so it shouldn’t not be too painful reconfiguring them. I assuming I can just created the new directory and present it as an NFS Export and then just copy the data to the new location and mount the new export. Does this sound correct?
dynamox
9 Legend
•
20.4K Posts
0
April 3rd, 2014 12:00
yes, unix admins will need to change the path
ryan_meyers
1 Rookie
•
17 Posts
0
April 3rd, 2014 12:00
Thank you for the reply. I wish I would have seen the link you attached before we ever created a directory on our Isilon. We created all of our agency folders in the root of ifs when in hindsight we should have created a folder similar to “ClusterA” in your example since we do in fact replicate to another location. Which in turn replicates back to this location. Fortuanetly we have not started putting anything other than replicated data on our remote side so I can at least create a “ClusterB” on that side before we do start using it.
As for my initial issue of how to handle the NFS exports I think I will create a second folder for each agency in /ifs that will be just for NFS shares. i.e ifs/personnel and ifs/personelnfs. Fortunatley we do not have very many created so far so it shouldn’t not be too painful reconfiguring them. I assuming I can just created the new directory and present it as an NFS Export and then just copy the data to the new location and mount the new export. Does this sound correct?
crklosterman
450 Posts
0
April 3rd, 2014 20:00
use chmod +ai from the cluster CLI. Isilon has enhanced chmod to be able to modify ACLs, so for all the options, look at 'man chmod'. Also to look at the existing ACLs, do an ls -le /path.
cincystorage
2 Intern
•
467 Posts
0
April 3rd, 2014 23:00
If you are still running and older version of OneFS you can use setfacl, but it is depreciated. In new versions you need to use chmod.
"chmod +a" will add an ACL to the top of the local allow and local deny lists.
"chmod +ai" will add inherited entires of the ACL
The correct form for an ACL order is:
local deny
local allow
inherited deny
inherited allow
If, for whatever reason, you need a specific order of ACLs you van use "chmod +a#" or "chmod +ai#" for inserting at a specific location.
To remove an ACL you can "chmod -a". If you need to remove all ACLs you can use a brute force option, "chmod -N or chmod -RN for recursive" which will delete all ACLs and write a null ACL.
I also have a script which will clone permissions (including ACLs) from a source file onto a target which you can find here. You can also use a PermissionRepairJob to do the same thing, but may be overkill if you need just a few files.
crklosterman
450 Posts
0
April 4th, 2014 06:00
Mark, I use Komodo a Perl IDE when working with Perl. It suggested a few syntax tweaks to your script, so I've made them, and would like to send you the revised copy, if you want to reach out to me directly with your contact info. (nothing really major).
Chris Klosterman
chris.klosterman@emc.com