Don't understand job "File Copy"

[E.Kok]

Hi,

for the first time I created a "File Copy" job but it doesn't work. Maybe I'm doing something wrong?

As a source I selected 'This server' and under 'Items to copy' selected a directory on a mapped drive. Is that allowed?
It shows as \\servername\share\dir\subdir and the subdir is being created at the remote site being an ESX-host. The subdir shows up on the appointed datastore.

So this seemed all fine exept after that nothing happens anymore. The state remains at 0% and never finishes and no files appear on the other end.

Any suggestions?

Ed

[foggy]

Ed, mapped drives are only available for users logged on to the computer interactively, they are created at logon and removed at logoff, and cannot be accessed by services. Are you able to copy files if you specify the UNC path to the source folder? If not, I would recommend opening a support case to let the guys review the full log files and define the reason of such behavior. Thanks.

[E.Kok]

He foggy,

as a source it is not possible to add an UNC-path. The 'Add'-button just shows physical AND mapped drives. If I choose a mapped drive it is auto-magically translated in UNC.
This gave me the impression that it is OK to use it like this. And when the job is started it does find the dir-structure and it is being created at the remote side. But that all.
When I kill the job (have to reboot ) the job shows: "Failed to copy item 'FileName' Error: Client error: End of file".

Just created a support-ticket [ID#5168627]
Recent logfiles are in support-ticket [ID#5168304]

[foggy]

Oh, yes. There's no way to specify UNC explicitly, but the product automatically transforms the path to UNC format. This works in our lab so you'd better investigate further with support team on this issue.

[E.Kok]

Support helped me to drill down to the cause: the service Veeam Backup Proxy needs to run with account that has privileges on the source. So not a real bug but maybe a little strange that the install-procedure doesn't mention this.

Ed

[foggy]

Ed, thanks for updating the thread with the resolution!