Home / server / Questions / 892031
Accepted
James White
Asked: 2018-01-14 00:18:49 +0800 CST

Robocopy Error 50 Accessing Destination Directory (Request is not supported)

  • 772

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.

windows

2 Answers

  1. Best Answer

    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.

    • 1

  2. 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.

    • 0