Forum Discussion

Guide

Dec 26, 2015

Solved

ReadyNAS 314 USB failures with Robocopy

I am using ROBOCOPY to backup data to a 4TB WDC hard drive via an OWC USB 3.0 enclosure connected to one of the rear ports. The command is

robocopy m: s:\aatest /e /R:1 /MIN:1 /TS /NP /FP /NDL /XX /FFT /XF ._* .ds_* /XD Recycle* snapshot /LOG+:s:\aatestlogrobocopy.txt

Where m is a share on the NAS, and s: is the mapped drive name.

The log file that it creates contains this: "ERROR 50 (0x00000032) Changing File Attributes s:\aatest\ The request is not supported."

I Just re-formatted (again) the HDD via ReadyNas 4.6.1 from my MacBook as NTFS, and I run the command from a Windows 10 PC.

I have no problems accessing the contents. It leaves the log find and the top level folder on the USB drive, but it goes no further.

I have granted all the access I can think of, Network access is Anonymous (as are most all the shares on the internal drives), but File Access says that "The feature is not supported for the selected share/device", not that I know if it is good or bad.

Things were OK until a few weeks ago (It was formatted as FAT32, and had hit its limit, I have these warnings in the log: "Share: Consumed space on folder USB_HDD_8 exceeds 82% of the quota (1.6 TB)."

Any advice?

Other Discussions

StephenB
Dec 26, 2015
The idea on /copy:dt was to explicitly exclude the attribute copy. The forum firmware turned the :d into an emoticon (an annoying habit it has).

PWS442 wrote:

I copy successfully when hooked up directly to the PC. It just seemed that the USB port on the rear was a good thing. Am I wrong?

If you are driving the backup from the PC, it is better to use a direcly connected USB drive. Otherwise you are transfering all the data over the network twice.

5 Replies

StephenB
Guru
Dec 26, 2015
Try adding /COPY:DT to your command line.

However, this is a very inefficient way to copy (the data goes from the NAS to the PC, and then back to the NAS USB drive).

Two faster methods:

(a) attach the WDC disk directly to the PC (so the data only transits the network once).

(b) use an RN314 backup job (so the data doesn't transit the network at all).
- PWS442
  Guide
  Dec 26, 2015
  Adding the T option did not copy new, nor modified files. Nothing was listed in the log. First it said the file I modified was skipped, then it said that it and the new file were both skipped. Using DAT (the default) also did nothing. Using /Copyall (DATSOU) said that I "do not have the Manage Autiting user right". DATS gave same error as before.
  
  I will look into the native backup options (can snapshots be excluded?), or revise my VB6 program and run it on the W10 box.
  
  I copy successfully when hooked up directly to the PC. It just seemed that the USB port on the rear was a good thing. Am I wrong?
  - StephenB
    Guru
    Dec 26, 2015
    The idea on /copy:dt was to explicitly exclude the attribute copy. The forum firmware turned the :d into an emoticon (an annoying habit it has).
    
    PWS442 wrote:
    
    I copy successfully when hooked up directly to the PC. It just seemed that the USB port on the rear was a good thing. Am I wrong?
    
    If you are driving the backup from the PC, it is better to use a direcly connected USB drive. Otherwise you are transfering all the data over the network twice.