Home > Storage > PowerScale (Isilon) > Product Documentation > Storage (general) > PowerScale OneFS Permission Repair Job > Permission Repair job modes
The PermissionRepair job can run in these different modes:
Mode | Description |
Clone | Applies the permissions settings for the directory specified by the Template File or Directory setting to the directory you set in the Paths fields |
For each file and directory in the specified Paths fields, converts the owner, group, and ACL to the target on-disk identity based on the Mapping Type setting | |
Inherit | Recursively applies the ACL of the directory that the Template File or Directory setting specifies to each file and subdirectory in the specified Paths fields, according to standard inheritance rules |
Caution: Running the PermissionRepair job in any of its modes affects the current access controls for the specified directory path. A best practice is to test and validate any new permissions configurations on a temporary dataset before making changes that affect the production environment.
In Clone mode, Permission Repair replicates the permissions from a template file or directory on the /ifs directory to the target.
Note: Clone mode does not append to the target's permissions but writes the template's permissions over the target's permissions.
Clone mode is preferred when a directory tree with a large file count requires a new set of permissions, such as switching from POSIX mode bits to Windows ACLs.
The following example shows clone mode using the CLI commands:
# touch file1 file2
# mkdir dir1
# touch dir1/file3
# ls -lze /ifs/data/target
total 53
drwxr-xr-x 2 root wheel 21 Feb 7 10:05 dir1
OWNER: user:root
GROUP: group:wheel
SYNTHETIC ACL
0: user:root allow dir_gen_read,dir_gen_write,dir_gen_execute,std_write_dac,delete_child
1: group:wheel allow dir_gen_read,dir_gen_execute
2: everyone allow dir_gen_read,dir_gen_execute
-rw-r--r-- 1 root wheel 6 Feb 7 10:05 file1
OWNER: user:root
GROUP: group:wheel
SYNTHETIC ACL
0: user:root allow file_gen_read,file_gen_write,std_write_dac
1: group:wheel allow file_gen_read
2: everyone allow file_gen_read
-rw-r--r-- 1 root wheel 6 Feb 7 10:05 file2
OWNER: user:root
GROUP: group:wheel
SYNTHETIC ACL
0: user:root allow file_gen_read,file_gen_write,std_write_dac
1: group:wheel allow file_gen_read
2: everyone allow file_gen_read
# chmod 777 /ifs/data/template
# chmod +a user admin allow delete_child /ifs/data/template
# ls -lze /ifs/data
...
drwxrwxrwx + 2 root wheel 0 Feb 7 08:45 template
OWNER: user:root
GROUP: group:wheel
0: user:admin allow delete_child
1: user:root allow dir_gen_read,dir_gen_write,dir_gen_execute,std_write_dac,delete_child
2: group:wheel allow dir_gen_read,dir_gen_write,dir_gen_execute,delete_child
3: everyone allow dir_gen_read,dir_gen_write,dir_gen_execute,delete_child
# isi job jobs start permissionrepair --mode=clone --template=/ifs/data/template --path=/ifs/data/target
# ls -lze /ifs/data/target
total 53
drwxrwxrwx + 2 root wheel 21 Feb 7 10:08 dir1
OWNER: user:root
GROUP: group:wheel
0: user:admin allow delete_child
1: user:root allow dir_gen_read,dir_gen_write,dir_gen_execute,std_write_dac,delete_child
2: group:wheel allow dir_gen_read,dir_gen_write,dir_gen_execute,delete_child
3: everyone allow dir_gen_read,dir_gen_write,dir_gen_execute,delete_child
-rwxrwxrwx + 1 root wheel 6 Feb 7 10:08 file1
OWNER: user:root
GROUP: group:wheel
0: user:admin allow delete_child
1: user:root allow file_gen_read,file_gen_write,file_gen_execute,std_write_dac,delete_child
2: group:wheel allow file_gen_read,file_gen_write,file_gen_execute,delete_child
3: everyone allow file_gen_read,file_gen_write,file_gen_execute,delete_child
-rwxrwxrwx + 1 root wheel 6 Feb 7 10:08 file2
OWNER: user:root
GROUP: group:wheel
0: user:admin allow delete_child
1: user:root allow file_gen_read,file_gen_write,file_gen_execute,std_write_dac,delete_child
2: group:wheel allow file_gen_read,file_gen_write,file_gen_execute,delete_child
3: everyone allow file_gen_read,file_gen_write,file_gen_execute,delete_child
Note: Changing the modes and ACLs of the template and running Permission Repair in clone mode copies the template directory’s permissions to the target.
PermissionRepair can also be started in clone mode using the WebUI, by going to Job Operations > Job Types > PermissionRepair > Start Job, and selecting Clone from the Repair Type drop-down menu:
Convert mode changes all the file and directory on-disk identities under the target path to the identity type specified by the Mapping Type field. The following table lists the on-disk identity type options:
Identity type | Description |
Global | Applies the system's default identity |
SID (Windows) | Applies the Windows identity |
UNIX | Applies the UNIX identity |
Native | If a user or group does not have an authoritative UNIX identifier (UID or GID), applies the Windows identity (SID) |
Convert mode is typically used for modifying the on-disk identity type and wanted permission settings.
For example, the following command converts the /ifs/data/target directory path to UNIX identity type:
# isi job jobs start permissionrepair --mode=convert --mapping-type=UNIX --path=/ifs/data/target
PermissionRepair can also be started in convert mode by using the WebUI. Go to Job Operations > Job Types > PermissionRepair > Start Job, select Convert from the Repair Type drop-down menu, and choose the wanted Mapping Type.
For example, to convert /ifs/data/test1 to the Windows SID mapping type:
A template directory is not required for the Permission Repair job when it is run in convert mode as nothing is being cloned or inherited.
Note: If you change the on-disk identity type, run the PermissionRepair job with the Convert repair type selected to ensure that the disk representation of all files is consistent with the changed setting.
As for the general job itself, PermissionRepair must be started manually (that is, not scheduled) and it runs by default with a low impact policy and priority value of 6 – although these default settings can be changed if wanted. If configuring a target directory, it must be below the /ifs directory in the file system hierarchy.
When Permission Repair is run in inherit mode, the current permissions of directories or files under the target directory are overwritten (not appended) by only the inheritable permissions of the template directory.
Inherit mode is typically used whenever an inherited ACE is added to an existing directory tree. Unlike Windows, which automatically traces all parent directories looking for inherited ACEs and adds them to the access check, OneFS manages ACL inheritance by explicitly adding the inherited ACE onto the security descriptor of the file or directory. This method means that OneFS can only respect inherited ACLs on newly created files and directories. As such, the Inherit mode PermissionRepair job needs to be run to update any objects in a tree that were present before an inherited ACL was added to the parent directory.
For example, the following CLI command runs the inherit-mode Permission Repair job on the /ifs/data/test1 file using the /ifs/data/template directory as the template directory.
# isi job jobs start permissionrepair --mode=inherit --template=/ifs/data/template --path=/ifs/data/test1
The PermissionRepair job can also be started in inherit mode using the WebUI, by going to Job Operations > Job Types > PermissionRepair > Start Job, and selecting Inherit from the Repair Type drop-down menu:
Note: With inherit mode, the template must be a directory because a file does not possess inheritable permissions.