Custom changes to disk security metadata should not be applied to the DiskSecurity.xml file itself. The disk security metadata can be contained in multiple files. All disk security metadata do not have to be contained only in the DiskSecurity.xml file. You can create any number of additional disk security metadata files. To customize disk security, you should create an additional file with the xml extension in the %plesk_dir%etc\DiskSecurity directory and specify additional security rules in the file. This will enable you to track changes and manipulate sets of security metadata easily.

To customize disk security rules in Plesk:

  1. Log in as administrator to a Plesk-managed server over Remote Desktop.

  2. Determine the Windows objects for which you want to set new security rules.

  3. Open the %plesk_dir%etc\DiskSecurity folder.

  4. In the folder, create a file with the xml extension. You can give this file any name.

  5. Create disk security rule entries in the file. To do so, use the XML file editor of your choice and the references below.

    Disk security rule entries have the same format as hosting security rule entries. To learn about the entry attributes in more detail, refer to General Security Metadata Structure. We also recommend that you see the example provided below.

  6. Once you have finished adding the security rules, save and close the file.

  7. Run the plesk repair utility with the --directory-permissions command and the -directory <path to the directory> option to apply the security rules to Windows objects. For example, to apply the disk security rules to the C:\Temp directory run the following command:

    plesk repair --directory-permissions -directory C:\Temp

For example, you have an application (say, IIS module) installed into the folder c:\Program Files\AppName. This module is used on customers’ sites, but it does not work properly because Plesk’s default security rules prohibit customers from accessing arbitrary folders on the disk. To resolve this, you can create a file named AppName.xml, add your security rules as described further, and place the file into the directory %plesk_dir%etc\DiskSecurity.

Security Rules Example

<?xml version="1.0" encoding="UTF-8"?>
<Entry EntryFlags="0x1" AccessMask="FullAccess" AceFlags="ThisFolderSubfoldersAndFiles" Path="C:\dir1" Account="Psacln" AccounType="1"/>
<Entry EntryFlags="0" AccessMask="ReadAndExecute" AceFlags="ThisFolderandSubfolders" Path="C:\dir1" Account="Psacln" AccounType="1" SubPath="dir2"/>
<Entry EntryFlags="0" AccessMask="FullAccess" AceFlags="ThisFolderSubfoldersAndFiles" Path="C:\dir1" Account="Psaadm" AccounType="1"/>


  • AccessMask=”FullAccess” indicates the “Full control” permission and AccessMask="ReadAndExecute"—generic execute.
  • EntryFlags specifies what to do with the AccessMask permission mentioned above. The "0" value of EntryFlags" allows the permission, while "0x1"—denies.
  • Path specifies the path to the object the security rule will be applied to (for example, C:\dir1).
  • SubPath specifies the remaining part of the object path if the path is not fully defined by Path.
  • AceFlags specifies if the object’s child objects (for example, subfolders and files) inherit the security rule.
  • Account is a Windows user account type. Psacln and Psaadm are not standard Windows system accounts. To be resolved in the system, they have AccounType=”1”.

Note: To fine-tune custom disk security, you can combine the “Deny” security rules of the higher level with the “Allow” security rules of the lower level and apply this combination to the same object. In the example above, the first security rule prohibits Psacln users from getting full control of the dir1 folder, its subfolders, and files. The second security rule, on the contrary, allows generic execute but only for one subfolder dir1\dir2. As a result, the combination of the two security rules allows Psacln users to list the dir1 folder and its subfolders but prohibits full control of files in dir1.