Robocopy to merge permissions

Not with robocopy, look at security explorer ($$$)

If you can find a copy of it,

there is a tool called fileacl, I think the latest version is 2.8 from 2008.

it will allow you to add ACE's to an existing ACL. It is all command line based, read the help thoroughly first.

it has a force function which uses SeBackupPrivileged oneFS 7.1.1 now allows that to work. otherwise the account you run the tool with needs access to change permissions, RunAsRoot on the share may allow it to work as well.

Rob,

can you please reference any papers that provide explanation and examples how PermissionRepair job works, i can't seem to find anything in the admin guide nor the support website.

FWIW it may be far easier/simpler/faster to run the PermissionRepair job on OneFS to modify all these ACLs in one fell swoop.

As Repair Permissions sets all ownerships and permissions plain identical on everything it finds in the subtree, I never found a situation where it could have been useful. Can't treat directories different from files, nor executables different from non-executables, nor can selectively act on say group permissions while keeping files' ownership intact. Therefore usually reverting to chmod/chown -R or more complex find constructs, with a bit of isi_for_array sometimes... A scriptable job type would be so much more powerful...

-- Peter

i am curious if it can reset ownership/ACLs given an example file, for example let's say i have a directory that used to be access by IIS, it has windows ACLs. Now i would like to change this directory so it's used by an Apache server running a Linux server. I would like to take all files in the existing IIS directory and change its ownership/permission to match a specific file that already has these parameters set, so something like this:

isi job PermissionRepair  -source /ifs/apache/goodpermissions  -target /ifs/iis/oldpermissions

you see where i am going with this ?

dynamox,

The Repair Permissions job is referenced in a few locations, though it does not have it's own document.  The best resource I found was in the online help files in the WebUI.  I found it by searching for Repair Permissions and it lays out the steps to use Repair Permissions.

Once you kick off a repair job, there isn't a clear explanation of what exactly it is doing.  Essentially it is using the job engine architecture (worker threads and cluster-aware task distribution) to accomplish a batch of metadata updates, in this case updating permission settings on a set of target files. 

There are references in the Web Administration guide and a few of the multi-protocol papers we have published.  If you have access to a Web interface, click over to Protocols -> ACLs to see the interface to the Repair Permissions Job.  (This is in a 7.1.1 interface, your version should have a similar path to the interface).

You will certainly need "x" permission bits set on the directories, and thus you'll get the same "x" permissions on all regular files -- kind of ugly, and afaik there are configs where Apache treats "x" files special. But if it's fine in your environment, just go ahead.

what is the actual syntax to do something like that, that was pseudo syntax that i made up

I would suggest starting with a small and isolated folder set and use the WebUI to see how it works for you.

In the WebUI, go to Protocols -> ACLs and click the Permissions Repair tab and start with the interface there.

From the CLI - I'm not 100% certain of the full construction but here's where I'd start:

# isi job jobs start --help

Edit: I will add the standard warning though, this is the Job Engine, so once you set it to work, it's going to assume you know what you are doing and spin up threads to get it done as quickly as possible.  You can significantly impact cluster performance and permissions across the cluster with these operations, so use caution and avoid production testing.  Thank you.

The use case here is a folder structure that needs an updated set of permissions.  On a windows server if you need to update permissions recursively, you grab the parent directory, update permissions, check the box to include all subfolders, hit okay, then go make yourself a coffee while it plows through ACL's for 20 minutes.  In Unix world, you can drop a few CHMOD commands to update a folder structure with the simpler posix mode bits.

This Job Engine option is simply extending that idea to a cluster scale.  So if you migrate a few TB of data, and you want the entire new folder structure to inherit permissions from the top level parent.  You can take advantage of the processing power of the cluster, and the worker threading of the job engine, to make those changes feasible.

So much like your example above, you'd want to clone a source GoodPermissions directory onto a target BadPermissions directory structure.  (potentially hundreds, thousands, or millions of sub-directories within).

You could also set that target BadPermissions directory structure to inherit a source GoodPermissions directory.

Or finally you can convert the owner, group and ACLpermissions to a specific on-disk identity.

I've printed the help file on this topic from the Web Interface as the most helpful resource I've been referencing and attached here.

what am i repairing ?  I need to understand what parameters i can pass to this job ?

I expect that with inherit permissions you have set sub-directories to inherit for the future.  Meaning if you were to change permissions on that parent directory, all sub directories would also have that change.  This also requires these directories to be sub folders, and not peer folders, as you can't inherit peer folders.

So if you had a very wide directory structure and wanted to correct permissions based on one folder being set properly, you would clone (as in your example). 

But if you wanted a single point of management for a deep directory structure, you'd go inherit and just manage the parent level perms. 

that's what i was suspecting by i am not seeing that during my test.  For example:

Source:

/ifs/data/marketing

Target:

/ifs/data/management

                    /HR

                    /IT

so when i configure the job i tell it to inherit where template is /ifs/data/marketing. Run the job and look at management, HR and IT directories. I would suspect that HR and IT directories would be inheriting ACLs from management but when i look under folder properties, Security, Advanced ..both HR and IT directories have under Inherited From column.  Am i doing something wrong ?

Thank you