Recently I have found myself enamoured with the microsoft tool subinacl, and only for a very small subset of it’s features, subinacl is a mcirosft tool for migrating objects (i.e. users and groups) and permissions between domains.

I was recently tasked with adding permissions to several NetApp shares so that once replicated the data would keep access in another domain. As all permissions were set as domain local as a best practice they obviously didn’t translate to the new domain. Subinacl will quite easily add or change ntfs permissions, even domain local permissions from another domain before the data has moved which made my job incredibly easy. The functionality isn’t the main reason I’m so happy with this tool (although it’s a pretty good reason)but rather how much better Subinacl is at applying permissions to deeply nested folder structures than icacls. The shares in question each had at minimum ~8.5 million files and folders each up to a whopping 22.5 million files and folders in a single share. Some of these shares were originally stored on DAS and when migrating them to CIFS I had the weeks long painful task of mapping drives to the deeper parts of the folder structure to use icacls after it had crashed, with Subinacl it managed to apply permissions at the deepest level of some truly massive shares in no time at all, the 22.5 million inode share took a little over a day.

In short I have thrown icacls out the window in favour of subinacl for setting permissions due to it’s speed and reliability, never mind the low memory usage and ability to perform multiple operations on acls with a single command. There are many lucky people who will have always known about the tool, but perhaps not realised how much better it is than icacls for modifying permissions.

Syntax for applying permissions to multiple sub folders (dont forget to add permissions to the /file (folder) at the top level first
subinacl /subdirectories [target path] /grant=[domain]\[user]=[permission]