About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
When a file is restored on a Windows file server, two things come back: the data and the permissions. The data is what people ask for. The permissions decide whether they can actually open it, and whether anyone else can.
One important source of permission problems after a restore is one design choice in Windows: permissions are not stored against names, but against security identifiers. This article explains what Microsoft documents about that design, what it means in common restore situations, and how to plan for it.
How Windows records who can open a file
Access control lists
Microsoft's article on access control lists explains that An access control list (ACL) is a list of access control entries (ACE). Each entry identifies a trustee and the rights it is allowed, denied or audited. There are two kinds:
- The DACL identifies who is allowed or denied access. When a process tries to open a file, the system checks the entries in the DACL.
- The SACL controls auditing: which access attempts are written to the security event log.
The same article describes two edge cases worth knowing. If the object doesn't have a DACL, the system grants full access to everyone. And if the DACL exists but has no entries, the system denies all access. In our reading, a restore that mishandles security information can therefore err in either direction: too open, or locked shut.
Security identifiers
The trustee in each entry is a security identifier (SID), not a name. Microsoft's article on security identifiers explains that A SID is used to uniquely identify a security principal or security group. Users refer to accounts by name; internally, Windows uses the SID.
The same article describes how a sign-in works: the system creates an access token containing the user's SID, user rights, and the SIDs for any groups the user belongs to. Access is decided by comparing those SIDs with the entries on the file.
For a domain account, Microsoft explains, the SID combines the domain's identifier with a relative identifier unique within that domain. Built-in groups, such as the local Administrators group, use a fixed identifier that is the same on every Windows computer.
Why recreating a name does not restore an identity
The security identifiers article states the rule directly: SIDs always remain unique. Security authorities never issue the same SID twice, and they never reuse SIDs for deleted accounts.
It gives an example. If a user leaves and their account is deleted, and they later return and a new account is created, The new SID doesn't match the old one, so none of the user's access from their old account is transferred to the new account.
In our reading, this rule applies just as much to restores. A file restored from a backup carries the SIDs that were on it when it was backed up. Whether those SIDs mean anything depends on the directory as it is now, not as it was then.
Common situations
A deleted account or group
If a user or group was deleted after the backup, the restored file still names the old SID. In our understanding, Windows cannot resolve that SID to a name, so tools that display permissions typically show the raw SID or an "unknown account" label. A raw SID is a reason to investigate, not proof that the entry is harmless: a restored identity, migrated account or temporarily unreachable domain may still make it relevant.
If the account was simply recreated with the same name, the new account has a new SID, and, as Microsoft's example shows, it does not inherit the old account's access. In our view, the better route when an account was deleted by mistake is to restore the account itself, which brings back its original SID, rather than recreating it. Active Directory object recovery is a separate recovery responsibility.
A restore to a different domain or forest
The security identifiers article explains that the domain part of a SID differentiates SIDs that one domain issues from SIDs that all other domains in the enterprise issue. A restore into a different domain, for example into a recovery environment or after a migration, brings files whose entries name accounts in the original domain.
In our reading, those entries only work if the original domain still exists and is trusted, or if the accounts in the new domain can be matched to them. Microsoft documents one mechanism that helps. The SID-History attribute Contains previous SIDs used for the object if the object was moved from another domain. Whenever an object moves, it receives a new SID and the previous one is added to its SID history. Microsoft’s security identifiers guidance explains that an old SID can remain in the access token and be used for access decisions. That can preserve access to files naming the old SID, subject to the trust and filtering conditions described below. It does not help where accounts were created fresh in the new domain rather than moved.
A restore to a standalone server
Local accounts follow the same rules at the scale of one computer. The security identifiers article explains that a local account's SID is unique to the computer where it was created. In our reading, files whose entries name local accounts on the original server will not be accessible through local accounts of the same name on a different server. Entries for built-in groups, with their fixed identifiers, do carry across. For example, an entry for the built-in Administrators group gives the destination computer’s administrators the corresponding access, not membership limited to the old server’s administrators.
A restore into a different folder
Restore tools usually offer a choice of whether to bring back the files' own permissions or let them take permissions from where they land. Microsoft's reference for wbadmin start recovery, the Windows Server Backup command line, describes an option that, when used, means the ACLs for the restored files will be inherited from the location to which the files are being restored. By default, it restores the files' own ACLs.
In our view, neither choice is always right. Restoring original permissions is usually correct when files return to their original place. Inheriting from the destination is often safer when files are restored somewhere else for a user to collect, because the original permissions may be broader or narrower than the new location intends. The point is to choose deliberately.
Copying is not the same as restoring
Files are often moved back into place with a copy tool after being restored elsewhere. In our reading, this is a point where permissions can be lost without an obvious copy error.
Microsoft's reference for robocopy documents its copy options. It notes that The default value for the /COPY option is DAT, meaning data, attributes and time stamps. Security, owner and auditing information are separate options that must be requested. The directory-copy default is /DCOPY:DA, meaning data and attributes; it is not a complete directory security record. In our reading, a default copy therefore lands files with whatever permissions the destination folder gives them, which may not be what the original files had.
Microsoft's reference for icacls describes related capabilities: it can save the DACLs of files to a file for later use, apply saved DACLs to files in a folder, and replace one SID with another throughout a set of files. In our understanding, these make it possible to record permissions separately from the data, and to re-point entries from an old account to a new one after a migration. A saved DACL file alone does not record ownership or SACL auditing entries. This article deliberately does not give their syntax; any such change across a file server should be tested on a copy first.
Owners and auditing are separate too
Permissions are not the only security information on a file. In our understanding, each file also has an owner, and may have auditing entries in its SACL. The robocopy reference lists these as separate copy flags: owner information and auditing information are each their own option, apart from security.
In our reading, both matter after a restore for different reasons:
- Owner. The owner of a file can change its permissions. If restored files end up owned by the account that ran the restore, rather than their original owners, the people who used to manage those files may lose that ability, and a service account may gain it.
- Auditing. Where auditing is configured on sensitive folders, for compliance or for detecting misuse, a restore that does not bring back the SACL leaves those files unaudited. Nothing fails, and nothing obvious changes for users. The gap only shows when someone looks for an audit record that was never written.
We recommend including owners and auditing in the decision about what a restore should carry, especially for folders that are audited for a reason.
Record permissions before you need them
In our view, the most useful preparation for permission problems is a record of what the permissions were meant to be. A backup holds the permissions as they were at one moment, but it does not explain them, and reading them back requires restoring them. A separate, readable record of the top-level folders on each share, who has access and through which groups, gives a recovery team something to check restored files against, and makes a cross-domain restore much easier to map.
Orphaned entries: clean up or leave alone?
After a restore, especially after account changes, files may carry entries for SIDs that no longer resolve. In our view, these are worth reviewing rather than removing automatically. An unresolved entry might belong to an account that was deleted correctly, in which case removing it tidies the permissions. It might also belong to an account in a domain that is temporarily unreachable, or one that is about to be restored, in which case removing it breaks access that would otherwise come back.
We recommend treating orphaned entries as a report to investigate after the restore is complete and the directory is in its final state.
Planning restores that keep access correct
From the points above, these are our recommendations:
- Protect the directory as well as the files. File permissions are only meaningful alongside the accounts and groups they name.
- Prefer groups over individual users in file permissions, so account changes affect fewer files.
- Restore accounts, don't recreate them, when an account was deleted by mistake.
- Decide the permission option each time a restore goes somewhere other than the original location.
- Check copy tools' security options before moving restored files into place.
- Test a cross-environment restore if a recovery site uses a different domain, and confirm users can open the files.
- Review orphaned entries after the directory is in its final state, rather than removing them during the restore.
Test both allowed and denied access
An administrator opening a restored file is weak permission evidence, because that account may have rights ordinary users do not. Test a representative authorised user and a user who should be denied, through the actual share path as well as the intended application. Account for group membership, inheritance and share permissions; a correct file ACL is not the complete network-access decision.
SID history is also not an automatic cross-forest recovery guarantee. Trust configuration, filtering and the supported migration process affect which identities are accepted. Do not weaken those controls simply to make old access entries resolve. Have the directory owner approve the identity mapping before applying it broadly. For audited folders, verify the audit policy as well as the SACL and check that the expected event is produced. A preserved auditing entry alone does not prove that useful audit records will be written.
Risks and limits of this article
- Based on Microsoft documentation as read on 11 November 2026.
- How tools display unresolved SIDs, and the recommendations, are our understanding and reading, labelled as such.
- No restores or permission changes were made for this article, and command syntax is deliberately not given.
- Share permissions, which are separate from file permissions, are a separate recovery responsibility.
Sources
Writer research: 11 November 2026. Independently reopened for review: 13 November 2026.
- Microsoft Learn: Access control lists
- Microsoft Learn: Security identifiers
- Microsoft Learn: SID-History attribute
- Microsoft Learn: wbadmin start recovery
- Microsoft Learn: robocopy
- Microsoft Learn: icacls
This article was originally published on .