Notice: This issue was corrected starting in CMon Server 21.1.1010.1 and newer versions, in that case creating a new Local Backup UNC based (network) device with a trailing backslash at the end of the path via the CMon UI, as was explained in this article, is not possible to do anymore starting in that version. If you have CMon Server locally hosted (self-hosted, locally installed) in your own environment then please upgrade to at least that stated version to fix this issue. And if you use a public CMon Server then that will already be taken care of for you, to be on the latest version already.
You may see backup failure if the Local Backup UNC based (a network path is the folder value) device was added via the CMon UI, if the Local Backup device "Path" field value was specified with a trailing backslash ("\") character at the end of the UNC path value, and in that case there is a high chance that backup will fail to that device if so. In certain cases, depending on if the specified UNC path value is the root share or not, is required to add the device via the CMon UI). Example failed backup job log, that states the trailing backslash character in the first error text at the top of the failed backup log in that case, and it states "Error: The network path was not found.", and the second error may state "Error e0010024: Unable to access this network share .." like this backup log example contains below:
Local Backup UNC based "Buffalo NAS' Device viewed via CMon UI (the assigned device for the above failed backup job):
The above example Local Backup UNC based (network path as the folder) "SCS-Nas-Local" (that uses the "Buffalo NAS" device as the target device) backup job has been failing due to a network device error in the backup log (at the top of the log for the error). The Job History can be viewed in the CMon UI website, that shows me this problem: https:. I believe that the problem with that is due to the trailing backslash character ("\") at the very end of the 'Path' variable that was used to define the "Folder" path value for that "Buffalo NAS" device, which you will need to remove that last character now by editing that device (which you cannot do via the client UI or the CMon UI unfortunately. You will have to manually edit a config file to fix that problem, and to do that read on. On the "SERVER" client (Agent) machine please edit the 'C:\ProgramData\NovaStor\NovaStor NovaBACKUP\Profiles\nsconfig.ini' configuration file using notepad.exe and remove the trailing backslash ("\") character at the very end of the 'Path=\\192.168.0.189\Backups\' line of text once you search that file for that "192.168.0.189\Backups\" line of text (without including the quotes in the search in that case). Then save the 'nsconfig.ini' file with that only change made in it and then run the "SCS-Nas-Local" backup job again to see if that works better for that run, to complete without a failed status that time, without the error at the top of the resulting backup log for that run. It is possible that the network credentials for the "Buffalo NAS" device were already correct and you just needed to remove that trailing backslash character at the end of the path value in that file for that device, but if the backup job still fails even though the error no longer states the trailing backslash at the end of the path in the error, like it did prior in your case (see the attached screenshot), then edit the device via the CMon UI, and edit the username and password field values there (you can't change the device path that way though) and save the change in CMon UI, and then wait one minute and then edit the 'nsconfig.ini' file again a second time after that credentials change is done, and verify that the 'Path=' variable value for the "Buffalo NAS" device still does have the trailing backslash character removed at the end of the value (because it likely will fail backup to that NAS device if it does keep the trailing backslash character in place I have seen for most customers, and in internal tests). Finally, run that same backup job again and see if it can complete without the failed status, and the same error as prior at the top of the log, after all of that. See the 2 x example screenshots for reference of the example backup job and the example device that backup job was assigned to that I'm talking about that is having the stated issue, that needs a manual correction to fix that. Once the example device is edited via the 'nsconfig.ini' file then you should be able to wait one minute and then refresh the "Devices" tab in the CMon UI for that Agent and then view the same "Buffalo NAS" device and the 'Path' field value should be corrected showing without the trailing backslash character in that case, like below (the same device edited manually via the single 'nsconfig.ini' file change should now reflect in the view device dialog in CMon UI like this, for the example device, the last "\" character in the 'Path' is no longer there in that case, but if not restart the "Backup Client Agent Service" and completely refresh the Agent details dialog, then navigate to the "Devices" tab and refresh that page, and that should work to correct it and look like this):
Note: This issue should normally only be seen if the Local Backup UNC based device was added via the CMon UI, not via the client UI. Creating that device via the client UI does not require that a trailing backslash character be appended to the end of a UNC path, unlike the CMon UI that does in certain cases (such as the example UNC path) require that in order for the device to add (save), in CMon Server v21.1.930.2 that is (at the time of this writing).
Notice: This issue was corrected starting in CMon Server 21.1.1010.1 and newer versions, in that case creating a new Local Backup UNC based (network) device with a trailing backslash at the end of the path via the CMon UI, as was explained in this article, is not possible to do anymore starting in that version. If you have CMon Server locally hosted (self-hosted, locally installed) in your own environment then please upgrade to at least that stated version to fix this issue. And if you use a public CMon Server then that will already be taken care of for you, to be on the latest version already.