“Error 5 : Access denied” is shown even with “roboocpy /B” | SEの道標
All About robocopy

“Error 5 : Access denied” is shown even with “roboocpy /B”

Windows denies access from who does not have permission even if you are administrator.

Unlike Linux, Windows denies access to files/folders that are not granted access even though he is administrator. The same is true for robocopy.

Robocopy has /B option and allows you to copy without permission.

What is robocopy /B option ?

When using the /B option with robocopy, it runs in a mode called "backup mode". When operating in this mode, you can copy files ignoring access permissions.

But it needs some conditions. It is to run as a user with the authority called "SeBackupPrivilege". This privilege is given to "BackupOperators" of the built-in group other than administrators.

So in order to operate robocopy in backup mode, you need to log-in as Administrator or user belonging to the BackupOperators Group, and execute robocopy /B with the privileges.

What is the case that "Access denied" in backup mode?

Even if it operates in backup mode, "Access denied" "0x00000005" "ERROR_ACCESS_DENIED" may be displayed. If backup mode works correctly, this error will not occur in theory. What is missing?

As a result of checking the actual behavior, when roboopy /B is done using CIFS sharing, the following two conditions seem to be necessary.

  1. Even for users who use CIFS sharing, it is necessary to run as a user with "SeBackupPrivilege".
  2. The user name must be the same between locally and remotely. (that is, the user who uses the local login user and the CIFS share is the same spelling.)

Passwords seem to be different.

If you get the above error, you may want to log-in to the Local Administrator and connect with the Local administrator of the remote server on CIFS shared connection too.

Still if the file is bad, may the file be special?

For example, a file encrypted by EFS (Encrypted File System) can not be copied to the remote unless it is the authorized user's privilege.

This is because EFS will attempt to automatically decrypt at the timing of copy to remote file system. If a user who is not himself does, access is denied (even administrator).

In this case, it can be copied with /EFSRAW option keeping encryption. However, because there is no key for decryption in the destination volume, it may not be a fundamental solution (it is safe if the principal backed up the EFS key).

If you set recovery agent, you can decrypt with administrator privilege.

In other cases, when trying to copy a Symbolic-Link file created on Linux to Windows, or when trying to copy files or folders containing Windows specific items (Alternative Data Stream etc) to Linux , it seems that there is a case that it may occur the above error.

Then the actions are different in each case. For example, about Linux based files and folders you can either copy it using rsync or restore it on a whole volume with the backup software. On the other hand, if the Windows specific thing is an Alternate Data Stream, do not inherit this data (do not add D in /DCOPY), or search and delete in advance with script.

コメント

Copied title and URL