3

Pretty straightforward script:

ROBOCOPY \\servername\S$\SCCM2012\SCCMPackageSource\Files C:\Files /S /COPYALL /MIR /IS /LOG:C:\Copy.log

I can run this as administrator just fine, and all the files get copied correctly. However when I push this script to a computer as an Application via SCCM 2012 and run it, the log file gives me the following:

NOTE : NTFS Security may not be copied - Source may not be NTFS.
2016/07/27 10:05:31 ERROR 5 (0x00000005) Accessing Source Directory \\servername\S$\SCCM2012\SCCMPackageSource\Files\
Access is denied.

Both the SYSTEM account and the SCCM Network Access Account have Full Control over that folder. The folder is not shared. Tried with the /ZB switch as well, but that didn't make any difference. Any thoughts? Thanks!

Matthias
  • 12,704
  • 13
  • 35
  • 56
  • If you run the script locally on a remote server, are you allowed to use network paths instead of local paths? – sambul35 Jul 28 '16 at 00:24
  • To find out whether the problem is system account or sccm related you can use psexec and locally start a shell as the system account. Then you can execute the script in the same way the application would execute it in terms of rights but bypass all the complicated sccm stuff – Syberdoor Jul 28 '16 at 07:28

4 Answers4

4

Add to robocopy parameter /NODCOPY - to not transfer parameters of file - it helped me.

2

Problem was resolved by Sharing the folder and giving Read access to the Everyone group.

Matthias
  • 12,704
  • 13
  • 35
  • 56
0

Ensure that both sharing permissions and security settings allow full control. Windows enforces whichever is the more conservative.

Andrew Roberts
  • 573
  • 6
  • 7
0

Found this result from google. If it help someone: Because of aborted (killed) robocopy process I had one folder with access denied. Even admins could not do anything with it (take ownership, open, delete, grant rights ...).

What solved our case was using checkdisk to repair the indexes. chkdsk /f f:

RokX
  • 334
  • 6
  • 16