Data Domain : ERROR: MSG-NFS-00005: Failed to do a filecopy, err = 2

Daily ASUPs may include near the top a summary of errors, which could show one or more of the folllowing one:

ERROR: MSG-NFS-00005: Failed to do a filecopy, err = 2.

That error informs a particular filecopy operation (which is the one issued when replicating backups in between DDs through the backup application BOOST libraries) that has failed, and returned error code 2.

If a customer checks the FS logs on the DataDomain that logged the error (ddfs.info log file, or those older rotated copies that may exist) around the date for the error logged, something like the following may be found there:

01/19 17:01:54.578 (tid 0x7ff55d90aaf0): filecopy ctx 547: server abandoned file: /data/col1/xxx-r_dev01/active/af662d48-00000006-1b7f20f5-587f20f5-64e60021-28d68730: No such file or directory 01/19 17:01:58.287 (tid 0x7ffea5b0c550): filecopy ctx 548: server abandoned file: /data/col1/xxx-r_dev01/active/87e5314d-00000006-7c7f3d55-587f3d55-67850021-28d68730: No such file or directory 01/19 17:01:58.419 (tid 0x7ffea5b0c550): filecopy ctx 545: server abandoned file: /data/col1/xxx-r_dev01/active/77c5a266-00000006-157f1331-587f1331-63ec0021-28d68730: No such file or directory 01/19 17:02:01.206 (tid 0x7ffea5cffdb0): filecopy ctx 541: file /data/col1/xxx-r_dev01/active/49b4cea8-00000006-b27ea2d6-587ea2d6-4b4f0021-28d68730 setting file size to 3999391092 01/19 17:02:01.206 (tid 0x7ffea5cffdb0): INFO: FM fm_dm1_attr_cache_refresh:404 - Get attributes for 2f5dc3:0:2f92bf:0:1e30d3b6:57681f66:0 failed with 2 01/19 17:02:01.206 (tid 0x7ffea5cffdb0): INFO: FM fms_set_size:1331 - Locking inode failed for 2f5dc3:0:2f92bf:0:1e30d3b6:57681f66:0, errno=5057 01/19 17:02:01.206 (tid 0x7ffea5cffdb0): INFO: FM fm_dm1_attr_cache_refresh:404 - Get attributes for 2f5dc3:0:2f92bf:0:1e30d3b6:57681f66:0 failed with 2 01/19 17:02:01.206 (tid 0x7ffea5cffdb0): WARNING: FM fms_close_common:713 - File 2f5dc3:0:2f92bf:0:1e30d3b6:57681f66:0 not found. Closing open structures...

This errors arise when, in the middle of a filecopy (while the backup application is running a backup clone to a distant DD) the customer or the backup application decided to abort the process before completion.

As long as there is some evidence the customer  or the backup application aborted those clones around the time the error was logged, then the errors can be safely ignored, and no side effects will exist, as the clone was aborted and the event will properly be logged on the application, which will retry later if so configured.