1

I have setup a robocopy script that runs on a daily basis and synchronises data from a specific folder on a Windows Server 2016 storage server to a SMB share on a QNAP NAS. The Windows Server is domain authenticated, while the QNAP uses a standalone user login. In the script this handled by net use so the server maps the QNAP share with the correct credentials rather than trying to assume or run under the scheduled task user.

net use \\QNAP\share /USER:<user> "<password>"

I have confirmed that the server can read/write to the share when mapped like this.

Having running the first sync manually to confirm the script/parameters are good before setting it up to run via task scheduler automatically, the following error was reported on a few directories in the log (various different locations). An example error is below, paths modified.

2018/01/12 06:38:16 ERROR 50 (0x00000032) Accessing Destination
Directory \\QNAP\share\example folder\something The request is not supported.

This is happening on the same folders each time robocopy is run. If I manually copy any of the folders that threw the error 50 to the destination with Windows Explorer, they copy fine, but even after doing so, the error 50 is still logged for the same locations. The error seems to be at the folder level, rather than specific files.

I am using the following robocopy parameters.

robocopy D:\local\folder \\QNAP\share\example folder /e /zb /fft /DCOPY:DA /COPY:DAT /r:0 /w:0 /XJ /XD RECYCLER .TemporaryItems /XF Thumbs.db ~* ._* *.inf .DS_Store /log+:D:\backuplog.txt /NFL /NDL

I'm struggling to find any information about error 50 from a robocopy perspective. It looks like error 50 is SMB related. It seems be related some either the attributes or properties of these specific folders not being able to be written to the QNAP directory. I tried removing the "A" (attributes) from the /COPY switch, but this didn't help.

James White
  • 654
  • 3
  • 17
  • 32

2 Answers2

1

I've managed to find the issue. It looks like its related to the QNAP share not being able to handle certain security folder properties/attributes of these folders. By default the COPY and DCOPY values are:

/COPY:DAT /DCOPY:DA

I assume the /E flag sets these by default.

Attributes do appear to be a problem, but in addition to that the DCOPY parameter also needs tweaking.

/COPY:DT /DCOPY:T

This then fixes the robocopy error 50 and folders that were previously throwing errors can now be written to the destination correctly along with the files within.

It is strange that this only started showing up for relatively new folders created, but it looks to be related to attributes/properties none the less. We have a mixture of Windows/macOS clients writing to the source, so it could well be specific macOS metadata behind these directories that have been throwing robocopy off.

James White
  • 654
  • 3
  • 17
  • 32
0

If you need to access network resources from task scheduler tasks you need to make sure the user account has the correct privileges to access the resource.

To make the task work at all times, choose Run whether user is logged on or not and enter a user account + password able to access the network share. Don't check Do not store password....

The misleading bit with scheduled tasks in Windows is when you run them manually they are always executed in your current user context, no matter what you configure them with. For testing, you need to temporarilty set up a trigger in the next minutes and have the task run automatically.

Zac67
  • 8,639
  • 2
  • 10
  • 28
  • Robocopy runs fine as a scheduled task. The error 50 occurs regardless of running manually or as a task. The script itself runs `net use` with the appropriate credentials so it maps the share with permissions. The task is also set to run with highest privileges and also run if not logged in or not, but task scheduler isn't the problem here. – James White Jan 13 '18 at 15:50
  • You should add these details - what is set up and what you've already tried - to the question. – Zac67 Jan 14 '18 at 09:25
  • Thanks. I have added a bit more detail, but ultimately I think the problem may be related to the specific attributes or permissions attached to these folders. The common trend with all the folders that throw error 50 are they are fairly recent folders created or recently copied. – James White Jan 14 '18 at 10:05
  • So, this happens somewhere in the middle of a running job? Possibly related to path length which is pretty limited with Windows? – Zac67 Jan 15 '18 at 20:40
  • Yes. During the job it is logged to the specified log file. Same directories each time. I thought robocopy could handle path sizes greater than 255? It certainly seems to have copied much longer paths from the source without issues. – James White Jan 16 '18 at 06:27
  • I've noticed that Windows clients have little problem *creating* long path directories and files, but when it comes to *walking* these paths they fail. Try robocopy against a Windows share (possibly with `/create`) to see if the problem is Samba-specific or general. – Zac67 Jan 16 '18 at 07:19
  • I don't think that's it either though. I ran `cmd /c dir /s /b |? {$_.length -gt 260}` to identify any long paths in the source dir. The max path is 315 characters and about 60 or so above the Windows "limit", but none of these have failed to transfer with robocopy. – James White Jan 16 '18 at 08:39
  • I'd run a `robocopy /create` against a Windows share anyway to see if this is server specific or not. – Zac67 Jan 16 '18 at 18:53