Ask the Community
Groups
Access Control List Permissions are not restoring with file restores - Connect IT Community | Kaseya
<main> <article class="userContent"> <h2 data-id="summary"><strong>SUMMARY</strong></h2> <p>This article explains why why restores may not include access control lists or security properties for certain users.</p> <h2 data-id="issue"><strong>ISSUE</strong></h2> <p></p> <p>Restores do not include access control lists or security properties for certain users.<br><br>User access lists are not shown in the security properties of restored files. The permissions on the restored files match the permissions of the parent folder.<br> </p> <h2 data-id="resolution"><strong>RESOLUTION</strong></h2> <p></p> <p>When using Agent File Based protection for Windows operating systems, or for CIFS or NFS NAS backups, ACLs cannot be restored for individual files or folders. To restore selective NTFS attributes, VM Host or Agent Image backups are required, and these attributes can be seen and copied by connecting via iSCSI to a FLR share. Otherwise existing ACLs and attributes are by Microsoft design inherited from the parent object data is recovered under resulting in prior file-specific permissions being dropped during recovery. <br><br>ACLs for Windows folders can restored to NTFS volumes via file agent backup when recovering entire paths to original volumes on original servers. Share-level permissions however are a component of the OS, not the files, and cannot be restored except through baremetal recovery of the server prior to data recovery. </p> <p>To restore the ACLs for full paths:</p> <ul><li>The restore must be to the original server (as the ACL contains not only domain users but also local admin and system account IDs they cannot be restored to a different machine). </li> <li>The restore must be to the original volume and path. </li> <li>If there are any existing files in the path restored, the parent folder permissions will be used instead of the ACLs, so to restore ACLs the entire path. To ensure this does not occur, the root folder of the objects being restored must not exist prior to restoring. </li> <li>Make sure that the "overwrite" option is used with the file restore from the advanced restore options menu. </li> </ul><p>To access this menu, select the client for which you wish you restore a backup, in the UI: Refer to this section of the admin guide for restore processes: </p> <h1 data-id="recovering-asset-level-backups"><a rel="nofollow" href="/home/leaving?allowTrusted=1&target=http%3A%2F%2Fguides.unitrends.com%2Fdocuments%2Frs-ueb-admin-guide%2F%23satori%2Frecovering_asset-level_backups.htm">Recovering Asset-level Backups</a></h1> <h2 data-id="cause"><strong>CAUSE</strong></h2> <p></p> <p>This behavior is by design of the Microsoft Windows operating system. It prevents restored files from having permissions that conflict with, or do not exist, on the server to which the files are restored, such as when recovering a file to an alternate path or a path containing existing files. Windows removes the permissions on those files and applies the current permissions of the folder to ensure conflicts are not created. This is the same behavior seen when copying a file to a share. Unitrends Agent cannot override this process.</p> </article> </main>