Highlighted
1 Copper

cannot change top-level ACL on isilon because of inheritance & propagation?

Hi, we have TBs of content (zillions of files & folders) hanging on Isilon fileservers. 
This has grown and grown over years.

This device is managed with "Windows" access control.
At the top-level, the existing situation allows (a) any user X to create new content in the top level folder, and also to (b) rename or delete folders/files in the top level folder even if owned by some other user Y.
This is, ahem, suboptimal.  We WANT restrictions (a) & (b).
But we are getting the advice that these restrictions cannot be made because ACL propagation to all of this has been attempted in the past, and even after weeks of chugging doesn't complete.  The existing ACLs below top-level are not uniform, fwiw.

Can't we place restrictions at the top level without triggering a propagation?
Top level has 3000 folders & files.

Can this be accomplished with Windows utilities?  Or must one use Isilon back-end utils?  Or is it simply impossible like we've been told.

Any thoughts & wisdom will be greatly appreciated!!

0 Kudos
2 Replies
Highlighted
1 Copper

Re: cannot change top-level ACL on isilon because of inheritance & propagation?

clarification:
This is, ahem, suboptimal.  We WANT restrictions, TO PREVENT (a) & (b).

0 Kudos
Highlighted
4 Beryllium

Re: cannot change top-level ACL on isilon because of inheritance & propagation?

The situation might me too complex for a simple silver bullet.

A great read to start:

https://www.dellemc.com/resources/en-us/asset/white-papers/products/storage/h17431_wp_access_control... 

As a builtin-in tool, the PermissionRepair job might be helpful for you; however probably not at share level but at folder level.

You said you want to stop users from creating folders directly below the share level; so I'd assume you plan to do some house-keeping and to reduce the number of existing folders at share level. With this, inheritance and propagation settings can be carefully re-thought at folder level, and removed from the share top-level.

hth

-- Peter

 

0 Kudos