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

I hit this during a multi-terabyte file server migration. The Robocopy command used /COPYALL, and the thinking was straightforward: copy everything so nothing important gets missed. The job ran overnight, the data copied, but the log was full of warnings about auditing information. Robocopy couldn’t copy the SACLs because the account running it didn’t hold the right Windows privilege.

Robocopy is one of those Windows tools that looks simple until you need to preserve more than just the files themselves. With /COPYALL, Robocopy tries to copy the data, attributes, timestamps, NTFS permissions, ownership and auditing information. That last part produces one of two errors. Run without the right privilege, Robocopy refuses to start:

text

ERROR : You do not have the Manage Auditing user right.
*****  You need this to copy auditing information (/COPY:U or /COPYALL).

Or the copy runs, but individual files and folders fail with:

text

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.

In both cases the problem isn’t the NTFS permissions themselves. Robocopy is trying to copy auditing information, and the account running it doesn’t have the Windows user right that requires. That right is called Manage auditing and security log, represented internally as SeSecurityPrivilege. Microsoft’s documentation for the Manage auditing and security log policy setting says it decides who can set object access audit options on individual resources such as files, Active Directory objects and registry keys, and that anyone holding it can also view and clear the Security log in Event Viewer.

There are two ways to deal with it: give the account the privilege if you genuinely need to migrate SACLs, or don’t copy auditing information at all if you don’t need it. For many file server migrations, the second option is simpler and carries less risk.

What /COPYALL is actually doing

Start with what Robocopy means by /COPYALL. Microsoft’s Robocopy command reference defines it as equivalent to /COPY:DATSOU, where each letter is something to copy:

So when you run robocopy C:\Data D:\Data /E /COPYALL, you’re asking Robocopy to copy considerably more than the file contents. The U flag is the one that matters here, because copying auditing information requires SeSecurityPrivilege.

Why being a local administrator may not fix it

This is where the error gets confusing. Being a local administrator and holding a particular user right are related, but they aren’t the same thing.

Run Robocopy elevated

The most common cause is simple: the Command Prompt or PowerShell window isn’t elevated. With User Account Control enabled, an administrator’s normal session runs with a filtered token that leaves out privileges like SeSecurityPrivilege. Open the shell with Run as administrator and the privilege is included. Check the token before running Robocopy:

cmd

whoami /priv | findstr SeSecurityPrivilege

If it doesn’t appear in an elevated window either, Robocopy can’t use it, and the cause is the policy assignment covered below. This matters most when Robocopy runs under a scheduled task, a service account, or any account other than the one you used to set up the server.

Check both ends of the copy

If you’re copying between two machines, for example from a local disk to a share on the new file server, the account needs Manage auditing and security log on both the source and the destination. Writing a SACL to a remote destination is done on the remote server, so a privilege that exists only on the machine running Robocopy isn’t enough. That’s a common reason the job starts cleanly and then logs ERROR 1314 against destination folders.

Check the effective 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. However, the Default Domain Policy value is Not defined, so a domain GPO or security hardening baseline can change the effective assignment without anyone remembering it happened.

On each server involved, open secpol.msc and go to Local Policies > User Rights Assignment > Manage auditing and security log to see which accounts and groups hold the right. If the setting is greyed out, Microsoft notes that a GPO is controlling it, which tells you where the real configuration lives. You can also export the effective local security policy and search it, which is useful for confirming the setting is actually present rather than relying on the GUI:

cmd

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

If Group Policy controls the setting

If the setting comes from a domain GPO, changing local policy may have no lasting effect. Group Policy applies settings in this order, with each level overwriting the one before at the next policy update: local, site, domain, then OU. To find which GPO is responsible, generate a report:

cmd

gpresult /h C:\temp\gpresult.html

After changing the GPO, force it to apply, then log off and back on before checking the token again:

cmd

gpupdate /force
whoami /priv | findstr SeSecurityPrivilege

Microsoft confirms that a restart isn’t required for this setting to take effect. However, any change to a user-rights assignment only takes effect the next time the account logs on, so the updated policy has to apply before that logon creates the new token.

The simpler fix: don’t copy SACLs

Before granting another account a sensitive user right, ask whether you actually need to migrate auditing information. If you need to preserve the file data, attributes, timestamps, NTFS permissions and ownership, you don’t need the U flag. Use /COPY:DATSO instead of /COPYALL:

cmd

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

That copies the data, attributes, timestamps, NTFS ACLs and owner, and deliberately leaves out the auditing information.

The /DCOPY:DAT is worth paying attention to as well. Robocopy’s default /DCOPY behaviour is DA, meaning directory data and attributes, so directory timestamps aren’t copied by default. Adding /DCOPY:DAT preserves them. For a file server migration where you want the destination to match the source as closely as possible, that matters. It’s also the kind of thing nobody notices until a user asks why every folder on the new server shows today’s date.

That’s what I did in the migration I described at the start. Rather than changing security policy just to make /COPYALL work, I reran the copy with /COPY:DATSO and /DCOPY:DAT. That kept the data, attributes, timestamps, permissions, ownership and directory timestamps, without needing the auditing privilege. I then reimplemented auditing on the destination through Group Policy, which turned out to be much cleaner than granting a broad user right to satisfy the original command.

What about /B and /ZB?

A related privilege issue often appears during the same kind of migration. Robocopy’s /B copies files in backup mode, and /ZB starts in restartable mode and switches to backup mode if access is denied. Microsoft documents backup mode as being able to bypass normal file and folder permissions when the account holds the right backup privileges. For example:

cmd

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

This uses different privileges from SeSecurityPrivilege. SeSecurityPrivilege relates to Manage auditing and security log, and only comes into play when copying SACLs with the U flag. Backup mode relies on the Backup files and directories and Restore files and directories rights, and without them Robocopy reports a similar startup error about not having the Backup and Restore Files user rights. So if you fix the auditing error by dropping /COPYALL, don’t be surprised by a different access-denied problem later when migrating protected files. /B and /ZB are the options to understand for that.

Do you actually need to migrate auditing?

SACLs are different from normal NTFS permissions. A DACL answers “who is allowed or denied access?”, while a SACL answers “what access should Windows audit?” For example, a SACL might audit successful or failed access to a sensitive folder.

If the destination server needs to keep auditing those folders in exactly the same way, preserving the SACLs may matter. 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’s also a point worth knowing about how auditing actually works. A SACL on a folder doesn’t generate audit events on its own. Microsoft notes that object access isn’t audited unless object access auditing is also enabled through Group Policy, the Local Group Policy Editor or auditpol. It’s entirely possible to migrate a set of SACLs that were never producing audit events in the first place.

Be careful about simply granting the privilege

It’s tempting to see the error, add the account to the policy and move on. That works, but it isn’t necessarily the right answer. The Manage auditing and security log right has security implications, because it also lets the holder view and clear the Security log. Microsoft’s best-practice guidance for the setting is direct: assigning it to groups other than Administrators generally isn’t necessary.

If the migration genuinely requires SACLs to be copied, granting the privilege to the account running the migration may be appropriate. Treat it as a temporary change and remove it once the migration is finished. If the migration doesn’t need SACLs, removing the U flag is usually a cleaner way to solve the underlying problem.

Choosing the right fix

If you genuinely need to migrate auditing information, run Robocopy elevated, make sure the account holds Manage auditing and security log on every server involved, and confirm SeSecurityPrivilege appears in the token with whoami /priv.

If you don’t need SACLs, don’t use /COPYALL just because it sounds like the safest option. For many file server migrations, this is enough:

cmd

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:

cmd

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.

Robocopy auditing error checklist

1. Confirm the exact error: the startup message about the Manage Auditing user right, or per-file ERROR 1314 when copying NTFS security.
2. Decide whether you really need to migrate auditing information (SACLs).
3. If you don’t, replace /COPYALL with /COPY:DATSO, and add /DCOPY:DAT to keep directory timestamps.
4. If you do, run Robocopy from an elevated prompt and check whoami /priv | findstr SeSecurityPrivilege.
5. Check Manage auditing and security log in secpol.msc on both the source and destination servers.
6. If the setting is greyed out, find the controlling GPO with gpresult /h.
7. After a policy change, run gpupdate /force, then log off and on before re-checking the token.
8. Grant the right only to the migration account, and remove it once the migration is finished.
9. If protected files still fail, look at /B or /ZB and the backup and restore rights.
10. Reapply auditing on the destination through Group Policy if you didn’t copy the SACLs.

References

• Robocopy command reference – /COPY, /COPYALL, /DCOPY, /B and /ZB options
• Manage auditing and security log security policy setting – what the right allows, defaults and best practices

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.