Advanced method (that is more in depth and is explained more thoroughly, and contains some screenshots, as compared to the "Simple" method guide that we also have to read here, which that "Simple" method guide would be preferable for you to start with, that has the minimal how-to content in it, but you may need to read this "Advanced" method guide for a further explanation or if you want more help on a particular section) guide for unable to create a new network based (UNC-based) 'Local Backup' device type in NovaBACKUP 21.x (if there are an open connections/or mapped network drives on that path at all, even if the share you are trying to add is not the same share that you have open connections for or mapped drives connected with, as long as the base portion of the path, prior to the share is the same (IP address or DNS address of the UNC network address that the share exists on), because if there are an open connections to that network share path already (which normally would be seen via the "net use" command output, but that is not always the case) then that device type may not be able to add, and doing so may show either a "Invalid credentials!" error or a "Network error! Unable to access this network share." error in a pop-up dialog). The need to first disconnect any existing open connection to the same network share path that may exist at the time of attempting to add a UNC based Local Storage device type in the initial 21.0.x version is due to a limitation in the backup client add (and edit) device code, which is why a workaround by you may be needed to correct it (at least temporarily to be able to get the device to add, and then after that there should be no issue with backing up to that same network share path device even if open connections do exist already, as the limitation in the code is only with the new device add or edit existing device functions, and not with the ability to backup to that device). Note: It is important to keep in mind that this device add and edit will not ONLY be seen for protected UNC share path to add as a UNC based Local Backup device, it will also be seen for non-protected UNC based Local Backup device, and in that case you would not think that "Network Credentials" would be needed to be specified but they are, at least in the initial 21.0.x version that is, and for that matter the issue won't be seen ONLY if you have an existing mapped network drive in place, it will also affect if you do not have a mapped network drive in place but you are only browsed to the UNC path location in question via Windows Explorer and have left that process open (and now that process needs to be exited). You may also see this issue if you just did disconnect an existing mapped network drive, or did delete the open remote path connection via the "net use" command or otherwise, but you have not yet rebooted the machine to try the device add again (on a fresh boot of Windows; so that would be worth trying as well if you keep getting stuck trying to add the device, even though the path is correct and even though you are sure that the "Network Credentials" tab fields were specified correctly for the device to add).
In order to create a new UNC based Local Backup device type (otherwise known as a Local FPI device), which is a new device type that was first added in the NovaBACKUP 21.0.x version, you may have to first take one or more steps (at least temporarily) to both disconnect the current mapped network drive that matches that UNC path that you will be trying to utilize in the new UNC based Local Backup device to create it in the client, and to also make sure to close out all open Windows Explorer sessions that are open to the UNC path that you specify in the new UNC based Local Backup device, in the first "Local Backup" tab, for the "Drive and Folder Path" (or the "Folder or Network Path") field value in that new device, and depending on if "net use" command output, run under the same user that your backup client is running under, check the output of that command to see if the output shows any entries, and if it does show an entry that matches the same "remote path" portion of the output as the UNC path that you specified in the device path, you will have to first disconnect that connection. If it is a mapped network drive you can disconnect it via the "net use /delete Z:" command (in a command prompt loaded under your user) or whatever the mapped network drive letter shows as in the output of that command. At least in NovaBACKUP 21.0 first public release version, the ability to add a new UNC based Local Backup device type may not work (and you will see an "Invalid credentials" error, if there is an open connection to that UNC path already that the device is trying to utilize to create for, whether that is due to a mapped network drive that is connected or if you have just an open Windows Explorer session open to that same share path, we have seen in testing. In that case you will have to follow the steps below on how to deal with that, as a temporary workaround (temporary meaning it won't affect backup to that device, but to be able to add the device you may be required to utilize the workaround to get the device to even add). Note: It will not always be the case that if there is an existing open connection to the same remote network path that there will be an entry seen via "net use" to the same remote path as the UNC based Local Backup device that you are attempting to add, in that case there likely will not be a connection visible seen in the "net use" command output in that case if your current Windows user is able to nagivate directly to the remote path via Windows Explorer, without needing to specify any credentials in a prompt (such as the credentials being read via a saved entry that is stored in the Windows Credential Manager, and in the case that your currently logged in user is already a member of the share permissions, in that case you won't be prompted to specify credentials if you were to navigate using Windows Explorer to the remote path, and in that case simply having a Windows Explorer session open at the time to the same remote path that the device was specified to utilize, even though you have the correct "Network Credentials" tab fields specified in the device to add) so in that case it won't always be the case that to workaround this problem you would be able to utilize the "net use" command to list all of the open network path connections and that you would second be able to utilize the "net use /delete" command to delete the existing connection that way, for it to even be feasible to workaround the problem using those two commands, as in that case there will be no entries or that entry for the remote path in question won't even be listed to delete that way, using that command. There are more clues about this in the second to last paragraph, in the next to last step in this KB article, to read about for more context.
As an example, even though I have correct credentials specified in the "Network Credentials" tab in my new UNC based "Local Backup" device, that utilizes a UNC path for the folder, if I have either a mapped network drive or an open connection to the same UNC path (which only needs to be open to at least the same share path, not a particular sub-folder under that share path) then I may have issues creating the new UNC based Local FPI device, and the error will be "Invalid credentials!" in that case when attempting to add the device, if those existing network connections are still open, as seen in this example where both the mapped network drive to Z: drive \\192.168.1.25\shared UNC path exists, as the Z: mapped netowrk drive that is also visible in the "net use" command output, and we also have that same UNC share path open in a single Windows Explorer session (in memory) for this same user that is running NovaBACKUP client trying to add the new UNC based Local Backup device to that same share path:
If this is the case that you reach the same above problem scenario, you can simply temporarily disconnect the open connection/handle/mapped network drive, etc. using a combination of loading a command prompt and performing the "net use" command to check the command output to see what the current active connections are (which will show "OK" status in the Status column usually if they are active) and then you can utilize the "net use /delete Z:" command (be sure to take note of the actual correct drive letter that matches the UNC path for the "remote path" value seen in the command output that matches the same UNC share path you are trying to specify in the new device) and/or Windows Explorer to do those items to disconnect the mapped network share (at least temporarily so that you can add the device, then you can re-enable the same share again), with the following command and workflow seen in this example screenshot:
Note: After the above is done, or if you did not have any mapped netowrk drives showing in the output of the "net use" command (executed in a normal command prompt launched by your current Windows user), or otherwise you did not see any other open connections listed in the output of that "net use" command that either did not list or you took care of deleting another way, please make sure to also now close out of all Windows Explorer sessions that are open on that same client machine, which I could not show you how to do in the above screenshot otherwise I wouldn't be able to see visually very easy that the Z: drive was removed in the "My Computer" drive listing in the "Network locations" section (seen in Windows Explorer). Please make sure that you also close any option connections to any remote paths that may be open, that match the remote path that you are trying to add the new device as. You may now want to confirm that all Windows Explorer sessions other than the main one, that doesn't actually have any folder paths open at all, is showing in your Task Manager > Details tab, like this screenshot does show. And in this case we show both Task Manager > Details running which only lists a single "explorer.exe" app running, which means it is just the basic shell running not open to any particular folder paths, as if that were true then it would be showing more than one "explorer.exe" task as running in that case, and we can also take the time to verify our second tab, which is the "Network Credentials" tab, 3 x credentials related fields, to confirm the credentials are correct to match that same UNC network share that we had specified as the folder path in the first tab:
And now after you have confirmed that the connection is no longer seen in "net use" command, and that you have closed ALL Windows Explorer sessions that may be open on this machine (or at least for the user you are currently logged in to Windows as running the backup client trying to add the new device), then you can retry the device add again, and this time you should have success with adding the same device, with no parameters changed other than you disconnected the active connections to the same UNC path that the device is trying to create as (as long as the path and the "Network Credentials" do match properly that is; if you still have issues please reboot the computer and then without doing anything else, load a command prompt and perfrom the "net use" command and check to see if there are any active open connections to that UNC remote path still, and delete those connections prior to attempting the device add; and do not attempt to use Windows Explorer to navigate to that same UNC path prior to the device add is done with success!). Here because the device was already added with success, after the prior step to this one, and we can see it listed in the Device tab now, we then double-click on that added device (or use the Properties button at the bottom right of the dialog) and we can see that the properties of the device do show the correct UNC path that was able to add with success that time, and now we can start using that new Local Backup device as a target device in NovaBACKUP client for backup jobs:
Note: If after the above steps are taken, and attempting to click OK to add the device still displays an error, in that case if the add device still displays either a "Invalid credentials!" error or a "Network error! Unable to access this network share." pop-up dialog error, then you can attempt to either delete any connection to that same remote path via the "net use" command to check the output, and then use the "net use /delete" command after that to delete the existing connection, that matches the same remote path, and then you can close all Windows Explorer sessions that may be open to that same remote network path, and then you can perform an end task on all of the "explorer.exe" tasks (processes) that are running as seen via the Windows Task Manager > Details tab, or you can choose to reboot the machine, and then after you log back on make sure that "net use" shows no remote path entry for the UNC network path that you are attempting to add next, and that there are no Windows Explorer sessions open, if there are close them, and that Windows Credentials Manager shows no saved "Windows" credentials entries for that same remote path as well, and if there are then delete the existing entry there. Then retry the device add after all of that, and make certain that ALL of the fields in the "Network Credentials" tab of the device to add are entered in correctly, before trying to press the OK button to add the device (which will perform a connection test with those credentials to the remote network path that was specified in the new device, and in that case due to a flaw in the logic of that dialog, it does not know how to check the credentials to authenticate with them if there are any existing open connections to that same remote path, as is normally seen via the "net use" command output, but that will not always the case that it will show in that command output, so that is why we have to be very clear in this paragraph for the steps to perform, including possibly a reboot before you can try adding the UNC based Local Backup device again. If you did choose to end task on all of the "explorer.exe" running tasks, then you can simply do a New Task in Windows Task Manager application that should be still running in your case, and go to the "File > Run new task" menu function and for the process to run type in "explorer.exe" and press enter or OK to start that Windows Explorer task (which will bring back your Desktop contents for one thing); but only do this last step if you had ended all "explorer.exe" tasks manually prior, as one of the steps you took to try to resolve this problem, as otherwise this last step would not be needed to do. Be sure that the device was able to add to the client, without displaying an error, before restarting that "explorer.exe" task.
After that is done and the device is confirmed to be in place, you can choose whether or not to map the same mapped network drive again, if that was in place prior under your user, that is if that was one of the steps that you had to take to do with this workaround that you had to disconnect temporarily in order to even add this Local Backup device to the NovaBACKUP client, which should not interfere with backup to that device (it should only affect adding the new device, or editing the credentials of that existing device, if there is an open connection to it outside of NovaBACKUP for the same user that is logged in to Windows that is running the client trying to perform the Local Backup device add/edit functions in that case).
Important Notes
- This issue affects both protected and non-protected network shares.
- Even if you think credentials aren’t needed, NovaBACKUP might still require them during setup.
- Once the device is added successfully, backups should work fine—even if connections to the path are open later.
- The credentials that you specify in the "Network Credentials" tab are encrypted by NovaBACKUP's own encryption method, to store those device parameters into the nsconfig.ini file (they are not stored in plaintext).
Note: The credentials that you specify in the "Network Credentials" tab are encrypted by NovaBACKUP's own encryption method, to store those device parameters into the nsconfig.ini file (they are not stored in plaintext).
If you still cannot get the 'Local Backup UNC (network folder) based' device to add in the client, then follow these special instructions, which may or may not already be part of the KB article guide above, or are extra to that:
If you are trying to add a 'Local Backup" device type that uses a network path as the folder, then please follow the contents of the current KB article guide above, that you are viewing now on that subject. But if that does not resolve the issue for you, then read on further to the special notes here, that are just a list of items to check and confirm and then try out in that case that you are still stuck trying to add this device type:
Before you go to add the device run this command by first starting a normal (non-admin) "Command Prompt" shortcut in Windows (without the single surrounding quotes, as was also already previously instructed, and likely was better described in that case, with a screenshot example in fact, to do in the above KB article): 'net use'
Then in the output of that command look for any mention of that same network path in the output text. If it exists then that is why the device can't add most likely.
Then load an "Administrator Command Prompt", to do that you will right-click on the "Command Prompt" shortcut and do a "Run As Administrator" on it, and repeat the same above instructions. If that network path is listed in the output, but maybe wasn't listed in the normal non-admin Command Prompt prior, that is likely why. You will need to issue the "net use /delete networkpath" or "net use /delete Z:" (without the surrounding double quotes), the first would be to delete the open connection that does not have a drive mapping on it, and the second would be to delete the connected network path that is listed in the output that has a mapped drive letter on the network path in that case. There will be a column in the 'net use' command output for "Local" and one for "Remote" and those are the columns to pay attention to here, for the "net use /delete" command. The other columns do not matter for this and you can ignore them. The existing connection, as long as the "Remote" path matches or closely matches the network folder address you are trying to use to do the "Add Device" with, no matter if in the first "Status" column in the output shows "OK", or "Disconnected", or a null value even in that first "Status" column, must be deleted in order for the "Add Device" to work in this case. You may also need to reboot after that as well to get the device to add, and make sure to run those two sets of commands above again in that order to check and confirm about any open connections to the network path you are going to try to add directly after that!
Do not try to specify the network folder path with a trailing backslash ("\") character in it when adding the 'Local Backup' UNC based (network based) device via the backup client, as that won't work, simply due to that trailing "\" character not being supported (even though the client does let you type that in as the last character in that field). If that doesn't work reboot the machine and retry the same add device operation again but confirm the output of 'net use' both ways first. Make sure you specify the "Network Credentials" tab in Add Device correctly, as when clicking OK to add the device (in any tab there) it will attempt to test the network connection by writing a file to the target path, and if there is an open connection to that same network path it will be rejected, as well as if the credentials do not match it will be rejected, and even if the network path isn't locked down and protected by a particular user and password it is 100% necessary to specify the correct "Network Credentials" tab info anyways, to a user that does exist on that network share path, that is added as a member to it, and that user must have "Admin" level rights to that network share in that case. Do not utilize any non supported by Windows characters in the "Device Name" field, that cannot be created as files or folders on a Windows based file system (that include these characters: ":", ";", "/", and "\"), so for instance the client will allow you to create a 'Local Backup' local drive based device with a "Device Name" field value of: "C:\", and the device will add that way, but backups will never work to it for sure, but for a UNC based network device to add, the "Folder and Network path" field just can't have a trailing backslash "\" character in it, and you may want to simplify the "Device Name" field value to be something like "NAS" in that case, to keep it simple as to not utilize any odd unsupported characters there (the client won't tell you the characters are unsupported currently, so that is going to be up to you to define it properly). I would recommend that the "Device Name" field should be very simple with no special characters in it, so you may want to the first time adding the device specify "NAS" for now without quotes, and for the "Folder or Network path" field value try to use the shortest possible base of the root share address as possible, for instance on a Buffalo NAS that would normally, be for the DNS address this example value: "\\buffalo\share" or be for the IPv4 address this example value (without the quotes): "\\192.168.1.100\share", and try to add like that again after following the complete KB article guide first before that. You should also if you are still having trouble here try adding the device by the IPv4 address format, in the "Folder or Network Path" field value next if you were using a mapped drive as the DNS address on that computer prior, and vice versa to that after reading and following the other instructions first. Finally, please confirm in the "Network Credentials" tab in the Add Device dialog that the domain, username, and password has admin rights on the target share as well, if the network share in question is not on a domain or is not Active Directory aware then leave the domain field blank (null). A connection test is always performed for this device type to add, and in that case it tries to create a folder on the target end and a file (DEVICE.ID) in that new folder on the target end, and if it cannot do that then a pop-up error message will be shown in the client that is generic in that it will tell you that either the credentials were incorrect or the network path could not be reached, or that it needs to be disconnected (as an open connection) first (the disconnect open connection is very important here, and the main KB article instructions cover that, for checking with 'net use' command and exiting out of all Windows Explorer "explorer.exe" tasks first then retry the device add after that!).
Other misc known reasons that the Add Device (for the 'Local Backup' UNC network based device type) can fail to add, or even if the device is able to add the backups to that device type can fail are detailed below, with workaround articles to read for you attempt to resolve the Windows OS group policy settings change issues (that could have come through via Windows Updates) yourself (that are not documented prior in this KB article):
It seems like some recent Windows 11 Updates (in or around "Windows 11 24H2") may be to blame for causing two group policy settings to change to be "more secure" for the settings, which leads to either the device can't add or we can't backup to it issues (to at least the 'Local Backup' UNC network based device type in 21.1.x). Windows 11 OS (no other OS's are confirmed but our feeling is that it seems likely it could also affect Server 2022 OS as well) with the latest Windows 11 Updates (24H2 or newer) installed on them, or if the first group policy setting uses certain settings choices, that Microsoft meant to make your system "more secure" (but that may break functions in the NBK client), in the "Configuring Active Directory to Force NTLMv2 via GPO" section of this third party article: How to Disable NTLM Authentication in Windows Domain. If this first item setting is true, that it is not set to utilize the last "Send NTLMv2 response only. Refuse LM & NTLM." available choice, where the default choice I believe is "Not Defined" for that setting, for the first group policy setting, that at least may cause backups to a 'Local Backup' UNC based network device to fail the backup with this main log error: "The specified network password is not correct, Error e001001e Failed to connect to the network location - Job processing failure". Please check and confirm that setting in your case, as it could affect even your ability to map a network drive directly in Windows OS (outside of doing it in the NBK client) for that one. There also is a problem that can affect backup to both the new modern and the old legacy backup device types in NovaBACKUP (all versions) that affect the SMB (Samba) protocol that the NBK client software uses to make the connection and store data to the target device, that is affected by a group policy setting named the "SMB client signing requirement:" to check and confirm in this second third party article (Microsoft.com): "Accessing a third-party NAS with SMB in Windows 11 24H2 may fail". Also, as a third item setting to verify and check, make sure that the SMB 1.1, 1.2 protocols are enabled as SMB protocols on the Windows computer in question, because if only the SMB 1.0 protocol is enabled then that can break the device add and the backup capabilities in NovaBACKUP in general in that case (at least for the Local Backup UNC network based device type). You can check what SMB protocol versions are enabled on the backup client computer by following this Microsoft guide article here. You can also download and utilize the third party "IIS Crypto GUI" app to visually see which TLS (Transport Layer Security) protocols are enabled on the backup client computer; I believe NovaBACKUP requires TLS 1.0, 1.1, and 1.2 to be enabled as TLS protocols in that case, or at least 1.1 and 1.2.
Additional help, for if after you do get the 'Local Backup' UNC network based device type to add, you then run into issues backing up to that device, and the main error or warning in the resulting backup log states "channel" in the lengthy set of error/warning text, you can try to set a "Run As" specified user in the backup job "Settings > Run As" dialog to correct that one issue, and you can read the how to below for that. Just know that not all Windows OS's will have this requirement that the backup job and the restore job (for a 'Local Backup' UNC network based device type) will require a "Run As Specified User" to be specified, that matches the same credentials as the device had specified in it already, in the backup & restore job "Settings > Run As" dialog in order to be able to work (to authenticate the backup or the restore with) in that case:
- If backups to the 'Local Backup' UNC network path based device, that utilize a protected share as the “Folder or network path value”, which requires “Network Credentials” to be specified in the device, if they fail to backup, and show a "channel" error or warning in the resulting backup log, which are usually long sections of warnings or errors that being with "channel" in the text in the log, you will need to do the following extra step, to edit that backup job that uses that backup device in that case, and you can read on for how to do that. On certain Windows Server OS’s it may be required to set the “Run As Specific User” setting in the backup job to the same user that is specified in the 'Local Backup' UNC based device in that case, otherwise the backup job runs may fail with a “channel” type of warning failure, that is unrelated to this problem. Some OS’s will need this and some other OS’s won’t need it, in that case I have seen that Server 2022 OS may not need the “Run As Specific User” set, but that Server 2019 and Server 2016 OS’s may need it in place in order to complete the backup without that “channel” type of warning failure. To do the latter part, a local user in Windows must be created new (via the 'lusrmgr.msc' command on a non-Domain Controller based Windows OS machine, but if on a Domain Controller machine you'd have to use the ADUC app to create a user with) that matches the same domain name, username, and password that you have assigned to the target Local Backup UNC based device, and if your NAS is not joined to a Domain or is not Active Directory aware then when creating the device you should leave the first "domain name" field blank, and then add that same new user to the local "Administrators" group on that backup client machine (or add that same new user to the "Domain Admins" group if the backup client in question is installed on a Domain Controller machine). Then via the Backup tab with that backup job open, click on "Settings" at the bottom of the dialog, and then click on the "Run As" tab, and then set the "Run As" tab settings to "Run As Specific User" and specify that same username and password (unless that is a Domain User in which case you would also fill in the first "Domain Name" field, but if the client machine in question is in a WORKGROUP and not joined to a Domain then leave that field null/blank), then save the backup job and run it again. Beyond that you will need to make sure that the specified "Network Credentials" that are specified in the 'Local Backup' UNC based device are specified correctly, and do pass the "Check Credentials" test in that same dialog inside the target device, via the "Device" tab. After passing the "Check Credentials" test in the "Settings > Run As" dialog in the backup job, once you do have a "Run As Specific User" specified, then you will click OK and then save that backup job, and then run that backup job manually again to see if it can complete with that "channel" error/warning in it, with a better success this time.