Why is my Robocopy script misbehaving (Error 59 and Error 53)

[Mat8iou]

I've had a Robocopy script that has worked fine for ages.

All it does is synchronises a remotely located network drive (Windows server accessed over OpenVPN) to a locally located network drive (SMB on Synology NAS).

It has worked find for over a year.

The last few days, it is constantly throwing up errors.

They are mostly error 29, but a few are error 53.

Below are some typical examples:
ERROR 59 (0x0000003B) Accessing Destination Directory
An unexpected network error occurred.

ERROR 53 (0x00000035) Time-Stamping Destination Directory
The network path was not found.

ERROR 53 (0x00000035) Scanning Source Directory
The network path was not found.

As far as I'm aware, nothing has changed on the source or destination machine.

The remote network drive is mapped. The local one is a UNC path.

If I browse with windows explorer to the source and destination locations I can access them fine.

Most directories seem to be checking fine - it is just a few that are flagging up these errors (my first thought is that perhaps it was the longest ones with a path length issue, but it isn't that).

Any suggestions as to what is going on here would be welcomed.

 

[continuum]

Can you throw a packet analyzer on the network?

You said nothing changed but I assume both are currently up to date on patches, maybe check those for any known issues?

 

[Mat8iou]

Can you throw a packet analyzer on the network?

You said nothing changed but I assume both are currently up to date on patches, maybe check those for any known issues?

Yeah - my only thought is patches, antivirus or firewall. There seems no logic though to the files it doesn't like - nothing odd with the file names, not unusually big or anything like that.

May start by seeing if the same files are skipped when I repeat it.

Doing a synch with another program for now, as I don't trust how much was being skipped.

 

[algebraist]

Mostly had ERROR 53 's myself on SMB connections. My solution to mostly alleviate it was /DCOPY:DT /COPY:DT and force it not to copy file attributes, just data and timestamps.

 

[Mat8iou]

Mostly had ERROR 53 's myself on SMB connections. My solution to mostly alleviate it was /DCOPY:DT /COPY:DT and force it not to copy file attributes, just data and timestamps.

Thanks - will give this a try. It is writing to an SMB connection, so it could well be this.

 

[algebraist]

Also a lot of my issues are related to my other Windows post. Our AD is hosed and auth went to hell.

 

[Mat8iou]

Also a lot of my issues are related to my other Windows post. Our AD is hosed and auth went to hell.

Interesting.

The problem seems to have gone away for me for a bit - wondering if it was at the other end on the Windows server, or if my transfer by an alternative method cleared the problem files.

 

[jediatzinger]

I'm learning to use robocopy... is /sec a switch you'd want to use for copying server image backups to a NAS?

 

[Mat8iou]

I'm learning to use robocopy... is /sec a switch you'd want to use for copying server image backups to a NAS?

At the moment I'm using /E /DCOPY:DAT /R:100 /W:3 /NDL /purge

I haven't been using /sec as any separate security settings (which there shouldn't be anyway) won;t be relevant to me when the files are on my local NAS.

 

[algebraist]

FYI /DCOPY:DAT is actually a default and doesn't need to be specified. If you ever look at the top of robocopy's output, it'll show you what it translated your switches into.

Including COPY and DCOPY options is only worth it if you're doing non defaults.

 

[Mat8iou]

FYI /DCOPY:DAT is actually a default and doesn't need to be specified. If you ever look at the top of robocopy's output, it'll show you what it translated your switches into.

Including COPY and DCOPY options is only worth it if you're doing non defaults.

Thanks. I wasn't aware of that.