Problem solve Get help with specific problems with your technologies, process and projects.

Backing up and restoring NTFS permissions on a specified volume

Serdar Yegulalp explains how you can harden your security by using the script NTFSBKP to back up and restore NTFS permissions -- either on one folder or to an entire drive.

New technology file system (NTFS) permissions can be notoriously troublesome beasts, and they're all the more difficult to deal with en masse. The easiest way to handle permissions for a lot of objects is via automation, such as a script of some kind.

As it turns out, the folks at Jerold Schulman International Inc. (JSI), in Atlanta, Ga., are enormously fond of batch scripts to accomplish many complicated administrative tasks, including helping to harden your security. One of JSI's scripts, NTFSBKP, works in conjunction with a Microsoft command-line tool (SubInACL) to allow you to back up and restore NTFS permissions on a folder or an entire drive.

The syntax for the script is:

ntfsbkp (drive_or_folder) (destination_folder) BKP|RST

where (drive_or_folder) is the name of the drive or folder whose permissions you're saving, and (destination_folder) is a folder where you're writing the backed-up permission information to. If you're backing up a drive's access control list (ACL) information, you need to specify the drive name with a double slash (i.e., C:\ would be rendered as C:\\).

SubInACL is a simple command-line program that can be put in your system's PATH and doesn't require any special installation (although it does come with its own .MSI installer).

When you run the script in backup mode, it doesn't generate any feedback unless there's a problem writing the security-description files. These files, generated by SubInACL itself, are simple text files that can be read and edited in Notepad (although you shouldn't edit them unless you know what you're doing).

There are many possible scenarios for using this script. For instance, if you're testing a number of possible NTFS security permutations for folders or objects and want to make sure you can always "roll back" to a known good state, you can use this script to back up everything before you start editing anything. It's easier to restore all the permissions automatically than to try and go back in and undo everything by hand.

NTFSBKP works pretty quickly. I was able to back up a 5 GB system's drive worth of permissions in a matter of seconds. However, the script is rather CPU-intensive. If you're running it on a server and you don't want it to hog the system, you can always run it using the start /low or start /belownormal command, forcing it to run in a lower-priority thread:

start /low|/belownnormal /b ntfsbkp (drive_or_folder) (destination_folder) BKP|RST

If you want to redirect the results to a file, simply add a redirect:

ntfsbkp (drive_or_folder) (destination_folder) BKP|RST > output.txt

This will redirect any output from the program to the file output.txt in the same directory as the batch file.

Note that if you back up permissions on a folder, then create new objects in that folder with different (i.e., non-inherited) permissions, the restore process will not overwrite the non-inherited permissions. Also, files with Unicode names or paths will have their permissions backed up and restored properly, so you can use this script on multilingual systems without compatibility problems.

Another important thing to keep in mind: NTFSBKP nominally stores security information by name, not by security identifier (SID). This has implications if you change or delete user accounts or groups between backup or restore operations. For instance, if you back up permissions on a folder that has a given user's permissions explicitly set on it, and then you delete that user, the restore operation won't restore that user's permissions at all. However, if you create a new account that has the same name, that account will be used as the permissions-holder for the restore operation on those objects, regardless of its SID!

If you grant user permissions to an object and then delete the user, there's still a reference to that user's SID in the Security tab for the object. If you run NTFSBKP in this state (and then restore the permissions later), the SID reference will be backed up and restored as is. Keep this in mind if you are using this script on a system where permissions are assigned explicitly to users and may change over time.

About the author: Serdar Yegulalp is editor of the Windows Power Users Newsletter. Check it out for the latest advice and musings on the world of Windows network administrators -- and please share your thoughts as well!

Dig Deeper on Windows 10 security and management