Windows 10: robocopy to retain ntfs permission while copying folders/files

I am trying to copy folders/filder using robocopy from serverA to serverB, I run the following and it wouldnt keep the ntfs permission at the destinationRobocopy E:\"share1" H:\folder1/share2" /E /DCOPYAT /Copy:datsou /R:0 /W:0 /V /MT:16 /TEE

:)

 

Copy NTFS permissions to a NAS with Robocopy

Hello,

I'm actually using Robocopy to copy a "home" folder with NTFS permissions to a NAS Synology. All theses equipment are on the domain, that will be named XXXXX in this post.

The permissions on the "home" folder are explicit, and not inherited from the parent folder. Also note that the SYNOLOGY NAS have the Windows Permissions activated.

The goal is to create a backup of this "home" folder to the NAS with the permissions.

Here is the Robocopy script that i'm using :

------------

set rep_log=C:\Script\log

set rep_sync_DATA=\\SRV1\e$\home\

set rep_sync_NAS=\\NAS-SYNOLOGY01\test01\backup\home\

robocopy %rep_sync_DATA% %rep_sync_NAS% /MIR /SEC /ZB /NP /XF thumbs.db /R:2 /W:5 /log:%rep_log%\Synchronisation_backup_nas.txt

-----------

The Robocopy script works well, and the files are well copied. EXCEPT one. On my "home" source folder, we can find on the permission list the XXXXXX\Administrators group. (explicit permission)

But, unfortunately, once the folder is copied to the NAS, it change the XXXXX\Administrators group to NAS-SYSNOLOG01\Administrators. This folder take the local domain of the NAS instead of my AD domain.

Please note that this "domain change" is only applied to this group, and the others lambda groups are not impacted by this strange change. (example XXXXXX\Sales group on source folder will be copied as XXXXXX\Sales to the destination)

The same script works perfectly if the destination is a USB HDD for example. It only happens if I want to copy to the NAS.

Any idea to fix this issue ? I faced this issue twice, with SYNOLOGY and with NETAPP technology. Whatever soft I tried to copy (robocopy or others), the result is the same...

Thanks for your potential help

Sébastien

 

Java.nio.file - Copying files

You can't copy a folder, thats why it generates an exception (you are trying to copy a folder using a copy file function).
You probably need to list all the files inside that folder and copy one by one

 

Robocopy NTFS to SMB

I'm using Robocopy to copy the contents of a folder called "MSBackups", which is stored on an NTFS HDD. The Destination folder is on a Samba share on my LAN. (Samba is installed on CentOS 7.9) Robcopy uses a "bat" file and runs as a scheduled task, this has been the case for few years with no issues but during the past few of months I've started to get errors when the task runs e.g. "access denied" and "network problems".

The backup fails on one of 2 folders, \user\AppData and / or \user\Data\$OF
The work round has been to stop the task (if needed) and use WinSCP to re-apply the perms on the Destination folder.

I then run the "bat" file manually "as admin" and it usually completes without errors but sometimes it doesn't and I have to repeat the perms thing.

This seems to be a "permissions thing" and could be due to updates on either Windows 10 or with Samba. My Robcopy "bat" file has worked fine for years using the "/mir" option but something has changed that has escaped my old brain! ( I have been retired for a few years and I'm not as sharp as I used to be)

I use Robocopy to copy other folders, all as scheduled tasks and never have any problems. The issue is specific to the "MSBackups", AppData & $OF folders but I can't see why.

I'm using Samba (4.10.16 )

The bat file below has worked for several years, with no errors.

robocopy \\source \\Destination\Data\msbackups /MIR /NDL /zb /LOG:C:\robotasks\logs\MSBACKtocentos.log

The /zb switch was added recently but hasn't helped.

I have amended the Robo switches to "/e /purge /NDL /LOG:C:\ etc" but that hasn't helped.

The /mir option should ignore the perms of the source and inherit the perms of the destination, as far as I know. Maybe something has changed?

The perms on the Samba shares are set to 2777 and all folders give access to the "smbgrp" and are owned by "fred".

The scheduled task is run as "fred" (user on the Win 10 box)
fred is a member of the smbgrp (Samba users)

When viewing perms (security) of the Samba share, from a Win 10 box, I get:-

Everyone - "special permissions"
fred (CENTOS\fred) - "special permissions" to
smbgrp (CENTOS\smbgrp) - "special permissions"

On the Win10 box (the source of MSBackups), "fred" (Square64\fred) has "Full Control"

I don't know if this is a Samba issue or a Robocopy issue or maybe the way that MS Backup / File History works with regards to "unique perms".
The Win 10 boxes on the LAN all log on using MS credentials. When the File History / MSBackup is run (AFAIK) it / they should inherit the perms of the (destination) NFTS HDD used to store the files. This may not be the case!

The "bat" file is never run as a user with MS Credentials. It is only run using either "fred" (Local Admin on the Win 10 box) or as "run as admin"

Checking Effective Perms for "fred" (Square64\fred) on the Samba share (MSBackups) from Win10 box I get "Code 0x80070534 No mapping between account names and security IDs was done"

All other shares give "No Mapping as above" but don't have any issues with robocopy.

Powershell to check smb version of server.

dir \\server\share

Get-SmbConnection

Results in version 3.1.1 being in use.

SMB v1.0 is disabled on Win10 boxes

So it seems to be a perms thing that only affects "App Data" & "$OF" folders, which may have "unique perms" that are not over ridden?

Grateful for any suggestions. I'm sure it isn't a problem with Robocopy switches and the "No Mapping between account names" is likely to be the problem but I don't know how to fix it :-(

Cheers