The OneFS job engine contains a Permission Repair job which, as the name suggests, provides an automated way to fix and manage access controls across a dataset. The job is run against a target, which can be a file or directory under /ifs. Depending on the job mode Pemission Repair enables:

  • Permissions to be copied from a template to target
  • The target to acquire inheritable permissions from a template
  • Changing the on-disk identity type stored within files and directories

Compared to the UNIX 'chmod' command, Permission Repair is considerably more efficient becuase it performs its operations in parallel across all nodes in the cluster (albeit using the same system calls that chmod uses). As such, Permission Repair is a much faster way to effect large scale permissions changes across a sizable directory tree.

The Permission Repair job itself can be run in three different modes:





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 access control list (ACL) to the target on-disk identity based on the Mapping Type setting.


Recursively applies the access control list (ACL) of the directory that is specified by the Template File or Directory setting to each file and subdirectory in the specified Paths fields, according to standard inheritance rules.


The job can be initiated via the OneFS WebUI by navigating to Cluster Management > Job Operations > Job Types > PermissionRepair > Start Job.

Or via the ‘isi job jobs start’ CLI command, with the following available options:


Command Option



Path to repair.

--mode=<clone | inherit | convert>    

Mode for Permission Repair (clone, inherit, or convert)

--type=<system | sid | unix | native> 

Identity type for Permission Repair (system, native, UNIX, or SID)

But first, a quick review of OneFS permissions configuration and reporting.

For OneFS to natively support concurrent, multi-protocol data access, it maps the POSIX mode bits from the NFS world to the access control model of the Windows SMB protocol, and vice versa. To achieve this, OneFS provides:

  • Transparent mapping of an on-disk identity to the correct requesting protocol.
  • Equivalency method to transform authoritative permissions into a form that the requesting access protocol can comprehend.
  • Permissions representation of where one permission style (ie. ACL) is authoritative and the other an approximation (ie. mode bits).
  • The ability to configure how OneFS manages permissions for different environments.
  • A default access control policy that optimally merges new permissions with existing ones.
  • A ‘Synthetic ACL’ that approximates the mode bits of a UNIX file for an SMB client.


Within OneFS, each ACE within a security descriptor is displayed as a single line prefaced by an index number and containing the following:


ACE Property



The identity to which the ACE applies

Allow or Deny

Whether the ACE allows or denies the permissions listed as part of the ACE


A list of one or more permissions that are allowed or denied by the ACE

Permissions words

These indicate flags that affect inheritance behavior, if present in the ACE


The identity can be one of three types: user (listed as “user:”), group (listed as “group:”), or the special identity, everyone. For directories, it can also be one of two special template identities: creator_owner or creator_group. When present in the ACL of a containing directory, these template identities are replaced in the ACL of a newly created file system object with the specific user and group of the respective creator.


An ACE can optionally contain flags that specify whether it is inherited by subdirectories and/or files. Inheritance takes place when objects are created. Modifying an inherited rule affects only new files and subdirectories, as opposed to existing ones.


The following flags specify the types of inheritance for permissions in the ACE:


Inheritance Type



Only files in this directory and its descendants inherit the ACE.


Only directories in this directory and its descendants inherit the ACE


This ACE will not propagate to descendants (applies to object_inherit and container_inherit ACEs)


The ACE does not apply for permissions to this object, but will apply to descendants when inherited


The ACE was inherited



To help support multi-protocol permissions mapping, OneFS has extended the ‘chmod’ and ‘ls’ CLI commands to provide more fine grained access control configuration and reporting.

In OneFS, the ‘ls’ command has a ‘-e’ flag extension, which reports on any Windows-style Access Control Entries (ACEs) the security descriptor contains, in addition to the traditional POSIX mode bits. For example, consider the following file: /ifs/data/file1.txt.


A regular long listing (ls –l) on this file shows the POSIX mode bits (644), as expected:


# ls -l /ifs/data/file1

-rw-r--r-- +  1 root wheel  6 Feb  12 10:49 /ifs/data/file2


Note the plus (`+') character following the mode bit representations. This plus indicates that either the file has an NTFS ACL, or a security descriptor and the ACL is NULL. A space here (‘ ') indicates there is no security descriptor. Every file will have a default synthetic ACL that is created on the fly, based on the file's mode bits.  A file with a synthetic ACL will not have a plus `+' next to it, although the ACL will still be viewable if the -e option is used.  The (`+o') output indicates that a file is wide-open in terms of permissions.

Adding the ‘e’ flag to the command returns both the mode bits, plus the ACL contents:


# ls -le /ifs/data/file1

-rw-r--r--    1 root wheel  6 Feb  12 10:49 /ifs/data/file1

OWNER: user:root

GROUP: group:wheel


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


Note: The ‘–e’ option for the ‘ls’ command (or the ability to view ACL information in addition to mode bits) will not be available from any NFS clients that remotely mount a OneFS export.


Similarly, the ‘chmod’ command in OneFS has an ‘a’ mode extension, which allows for ACL and ACE (re)configuration. This includes:


Chmod ‘A’ Mode



Inserts a new ACE into the canonical location in the ACL.  If the supplied entry refers to an identity already listed, the two entries are combined.


Deletes ACL entries. All entries exactly matching the supplied entry will be deleted. If the entry lists a subset of rights granted by an entry, only the rights listed are removed. Generic rights (generic_all, generic_read, etc.) can not be subtracted, they can only be added.


When a specific ordering is required, the exact location at which an entry will be inserted is specified with the +a# mode.


Individual entries are rewritten using the =a# mode. Note: Some shells require "=" to be escaped with the "\" character.




For example, the following command will add a ‘deny file read’ ACE for the group ‘Administrators’:


# chmod +a group administrators deny file_read /ifs/data/file1


# ls -le /ifs/data/file1

-rw-r--r-- +  1 root wheel  6 Feb  12 10:49 /ifs/data/file1

OWNER: user:root

GROUP: group:wheel

0: group:Administrators deny file_read

1: user:root allow file_gen_read,file_gen_write,std_write_dac

2: group:wheel allow file_gen_read

3: everyone allow file_gen_read


Since mode bits are a subset of the more comprehensive Windows ACL model, mapping mode bits to ACLs is straightforward. When a Windows client changes the permissions of a file with an ACL, no information is lost because OneFS stores the original ACL and replaces it. Similarly, when a Windows client changes the permissions of a file with mode bits, OneFS replaces the file's synthetic ACL with an actual ACL which is equivalent to the mode bits. However, things get a little trickier when the permissions of a file protected by an ACL are a modified via chmod. OneFS must map the permission changes between two non-corresponding security models. To do so, OneFS, in its default setting, merges the ACL with a patch derived from the change in mode bits.

For example, consider the file ‘file2.txt’. This file was created by a Windows client, and the permissions listed are the generic access rights for files and directories. OneFS correctly approximates the mode bits as ‘764’:


# ls -le file2.txt

-rwxrw-r-- + 1 WIND1\jdoe WIND1\tme 2056 Feb 12 10:18


OWNER: user:WIND1\jdoe

GROUP: group:WIND1\tme

0: user:WIND1\jdoe allow


1: group:WIND1\tme allow file_gen_read,file_gen_write

2: everyone allow file_gen_read


If the mode bits are changed from ‘764’ to ‘744’, OneFS removes the write permission of the primary group, while preserving the other permissions:


# chmod 744 file2.txt

# ls -le file2.txt

-rwxr--r-- + 1 WIND1\jdoe WIND1\tme 2056 Feb 12 10:18


OWNER: user:WIND1\jdoe

GROUP: group:WIND1\tme

0: user:WIND1\jdoe allow


1: group:WIND1\tme allow file_gen_read

2: everyone allow file_gen_read


In most cases, a result like this preserves the ACL information and minimizes conflicts between actual and expected behavior. However, there are some anomalies to be aware of.

Here’s an example where the mode bits and ACEs do not map directly. If the mode bits on the file (file3.txt) are changed from 750 (rwxr-x---) to 650 (rw-r-x---), the resulting merge removes the right to modify the owner in the object’s security descriptor, leaving the user with the standard right to modify the discretionary access control list in the object's security descriptor:


# chmod 650 file3.txt

# ls -le file3.txt

-rwxr-x--- + 1 WIND1\jdoe WIND1\tme 807 Feb 12 10:19

  1. print.css

OWNER: user: WIND1\jdoe

GROUP: group: WIND1\tme

0: user: WIND1\jdoe allow


1: group: WIND1\tme allow file_gen_read,file_gen_execute

2: everyone allow std_read_dac,std_synchronize,file_read_attr

The following table attempts to provide an equivalency of permissions entities between Windows access rights, POSIX mode bits, and OneFS permissions.


POSIX Mode Bits (Approximation)

OneFS Representation

Windows ACE







drwx or -rwx

dir_gen_all, file_gen_all


--w- or d-w

append, add_subdir
































d-w- or --w



dr-- or -r--



drwx or -rwx



drwx or -rwx







In the next blog article in this series, we’ll take a closer look at the three Permissions Repair job modes.