How to Fix “You do not have the Manage Auditing user rights” Error in Robocopy

Robocopy is one of those Windows tools that looks simple until you start copying a large file server and need to preserve more than just the files themselves.

If you use /COPYALL, Robocopy attempts to copy the data, attributes, timestamps, NTFS permissions, ownership and auditing information. That last part can produce an error that catches people out:

2026/07/29 22:14:03 ERROR 1314 (0x00000522) Copying NTFS Security to Destination Directory D:\Data\Finance\
A required privilege is not held by the client.

The important part of this error is not the NTFS permissions themselves. Robocopy is trying to copy the auditing information, and the account running Robocopy does not have the Windows user right required to do that.

That user right is called Manage auditing and security log, and internally it is represented by SeSecurityPrivilege. Microsoft documents this privilege as determining which users can specify object access audit options for individual resources such as files, Active Directory objects and registry keys, and notes that a user assigned this right can also view and clear the Security log in Event Viewer.

There are two ways to approach the problem:

1. Give the account the required privilege if you genuinely need to migrate SACLs.
2. Don’t copy auditing information in the first place if it isn’t required.

For many file server migrations, the second option is the simpler and safer one.

What /COPYALL is actually doing

The first thing to understand is what Robocopy means by /COPYALL.

Microsoft defines /COPYALL as equivalent to:

/COPY:DATSOU

Those flags represent:

So when you run:

robocopy C:\Data D:\Data /E /COPYALL

you are asking Robocopy to copy considerably more than the file contents.

The U flag is the important one here. It tells Robocopy to copy auditing information, which requires SeSecurityPrivilege.

Microsoft’s Robocopy reference documents the /COPY, /COPYALL, /DCOPY, /B and /ZB options.

Why being a local administrator may not fix it

This is where the error can be confusing.

Being a local administrator and having a particular Windows user right are related, but they are not the same thing. The effective user-right assignment can be changed through Local Security Policy or Group Policy.

Microsoft lists Administrators as the effective default for Manage auditing and security log on stand-alone servers, member servers, domain controllers and client computers. Note, though, that the Default Domain Policy value is not defined, which means a domain GPO or security hardening baseline can change the effective assignment without anyone remembering it happened.

There is also a difference between the account being assigned a privilege and that privilege actually appearing in the security token of the process running Robocopy.

Check the token with:

whoami /priv | findstr SeSecurityPrivilege

If the privilege isn’t present, Robocopy cannot use it.

This is particularly important when Robocopy is being run under a scheduled task, service account or another account different from the administrator account you used to configure the server.

Check the effective policy

On the server running Robocopy, open:

secpol.msc

Go to:

Local Policies → User Rights Assignment → Manage auditing and security log

Check which accounts or groups are assigned the right.

There is a useful visual clue here. Microsoft documents that when a local setting is greyed out, a GPO is currently controlling that setting. If you open the policy and can’t edit it, you have your answer about where the configuration is actually coming from.

You can also export the effective local security policy:

secedit /export /cfg C:\temp\secpol.cfg

Then search for:

findstr SeSecurityPrivilege C:\temp\secpol.cfg

This is useful when you’re trying to work out whether the setting is actually present rather than simply looking at the GUI.

If Group Policy controls the setting

If the setting comes from a domain GPO, changing the local policy may have no lasting effect.

Microsoft documents that settings are applied in this order through Group Policy, overwriting local settings at the next policy update:

1. Local policy settings
2. Site policy settings
3. Domain policy settings
4. OU policy settings

After changing the GPO, force the policy to apply:

gpupdate /force

Then log off and back on before checking the token again:

whoami /priv | findstr SeSecurityPrivilege

The important sequence is therefore:

gpupdate /force
log off
log on
whoami /priv | findstr SeSecurityPrivilege

Microsoft confirms that a computer restart isn’t required for this policy setting to take effect, but that any change to a user-rights assignment becomes effective the next time the account owner logs on. The updated policy needs to have applied before that logon creates the new security token.

If you want to identify exactly which GPO is responsible:

gpresult /h C:\temp\gpresult.html

The simpler solution: don’t copy SACLs

Before granting another account a sensitive user right, ask whether you actually need to migrate auditing information.

If the requirement is to preserve:

• file data
• attributes
• timestamps
• NTFS permissions
• ownership

then you don’t need the U flag.

A useful alternative to /COPYALL is:

/COPY:DATSO

For example:

robocopy C:\Data D:\Data /E /COPY:DATSO /DCOPY:DAT

This copies:

• D = Data
• A = Attributes
• T = Timestamps
• S = NTFS ACLs
• O = Owner

but deliberately leaves out:

• U = Auditing information

The /DCOPY:DAT is worth paying attention to as well.

Robocopy’s default /DCOPY behaviour is DA, meaning directory data and attributes. Directory timestamps are not included by default. Adding /DCOPY:DAT tells Robocopy to preserve the directory timestamps too.

For a normal file server migration, that distinction can matter when you’re trying to make the destination match the source as closely as possible. It’s also the sort of thing nobody notices until a user asks why every folder on the new server shows today’s date.

A real migration example

This happened during a multi-terabyte file server migration.

The initial Robocopy command used:

/COPYALL

The thinking was straightforward: copy everything so nothing important was missed.

The migration ran overnight and produced warnings relating to the auditing information. The data itself was copying, but Robocopy was unable to copy the SACL information because the account did not have the required SeSecurityPrivilege.

Rather than changing the security policy simply to make /COPYALL work, the migration was rerun using:

/COPY:DATSO

with:

/DCOPY:DAT

That removed the requirement to copy the auditing information while still preserving the file data, attributes, timestamps, NTFS permissions, ownership and directory timestamps.

Auditing was then reimplemented on the destination through Group Policy.

That turned out to be a much cleaner approach than granting a broad user right just to satisfy the original Robocopy command.

What about /B and /ZB?

There is another Robocopy privilege issue worth knowing about because it often appears during the same type of migration.

Robocopy has backup mode:

/B

and restartable mode with a backup-mode fallback:

/ZB

Microsoft documents /B as copying files in backup mode, which can bypass normal file and folder permissions when the account has the appropriate backup privileges. /ZB starts in restartable mode and switches to backup mode if access is denied.

For example:

robocopy C:\Data D:\Data /E /COPY:DATSO /DCOPY:DAT /ZB

This is a different privilege from SeSecurityPrivilege.

The important distinction is:

• SeSecurityPrivilege relates to Manage auditing and security log and is relevant when copying SACLs with /COPY:U.
• Backup mode relies on the Windows backup-related privileges to access files that the account otherwise cannot read.

So if you solve the ERROR 1314 problem by removing /COPYALL, don’t be surprised if you encounter a different access-denied problem later when migrating protected files. /B and /ZB are the other Robocopy options worth understanding.

Do you actually need to migrate auditing?

This is the question I would ask before changing security policy.

SACLs are different from normal NTFS permissions.

A DACL answers:

Who is allowed or denied access?

A SACL answers:

What access should Windows audit?

For example, a SACL might be configured to audit successful or failed access to a sensitive folder.

If the destination server needs to continue auditing those folders in exactly the same way, then preserving the SACLs may be important.

If the organisation is going to configure auditing again through its standard security policy on the new server, copying the old SACLs may not be necessary.

There is also a point worth noting about how auditing actually works. A SACL on a folder doesn’t produce audit events on its own. Microsoft notes that object access audits aren’t performed unless object access auditing is also enabled through Group Policy, the Local Group Policy Editor or auditpol.

So it is entirely possible to migrate a set of SACLs that were never generating audit events in the first place.

Be careful about simply granting the privilege

It can be tempting to see the error, add the account to the policy and move on.

That works, but it isn’t necessarily the right solution.

The Manage auditing and security log user right has security implications because it also allows the holder to view and clear the Security log.

Microsoft’s own best-practice guidance for this setting is direct: before removing this right from a group, check whether any applications depend on it, and generally, assigning this user right to groups other than Administrators isn’t necessary.

If the migration genuinely requires SACLs to be copied, assigning the required privilege to the account running the migration may be appropriate. If you do, treat it as a temporary change and remove it once the migration is complete.

If the migration doesn’t require SACLs, removing the U flag is usually a cleaner way of solving the underlying problem.

Which fix is the right one?

If you genuinely need to migrate auditing information, investigate the effective Manage auditing and security log policy and make sure the account running Robocopy receives SeSecurityPrivilege.

If you don’t need to migrate SACLs, don’t use /COPYALL simply because it sounds like the safest option.

For many file server migrations, this is enough:

robocopy C:\Data D:\Data /E /COPY:DATSO /DCOPY:DAT

And if you need Robocopy to fall back to backup mode when normal access is denied:

robocopy C:\Data D:\Data /E /COPY:DATSO /DCOPY:DAT /ZB

The key is understanding what Robocopy is actually being asked to copy. /COPYALL includes auditing information, and that brings SeSecurityPrivilege into the picture. If auditing isn’t part of the migration requirement, leaving the U flag out avoids the problem altogether.

References

• Robocopy command reference
• Manage auditing and security log security policy setting

Daniel Lutton

From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.