After upgrading an xSP Storage Server component from older version to newer version, you notice that xSP clients / client accounts cannot connect to it, backups fail and clients fail the Test connection to the xSP Storage Server. The error in the Masterlog.txt on the xSP Storage Server machine (default path C:\Program Files\NovaBACKUP Storage Server\Masterlog.txt) will at that time display an error: "ERRO Unable to get disk usage for path" and then it will state the backup storage path, in most cases that will be a network share / network storage path. An example of this error is shown here:
The primary reason why could occur:
This normally will occur just after an xSP Storage Server upgrade from one version to the other, because the "Backup Server" service on the xSP Storage Server system, seen in Windows Services (services.msc), has had the 'Log On As' setting reset back to the default which is Local System, and prior to the xSP Storage Server upgrade that "Backup Server" service had been specified to utilize a different user account for the 'Log On As' setting for the "Backup Server" service, than "Local System".
When upgrading the xSP Storage Server component the old "Backup Server" service is actually un-installed, and then re-installed, and because that particular service was re-installed it loses whatever custom Log On As user that you specified prior and simply utilizes the default Local System user which is the standard during new installations.
First of all you need to verify that your Backup Server service is showing "Status: Running", and take note of the "Log On As" setting, to know if it is using the default value of Local System or if it is custom set to a particular user that you configured it to run as. If the service is not started, go ahead and attempt to start it to make sure that it is running and then re-try your backup / test connection operation to see if that fixes it before proceeding. Here is what the "Backup Service" details should look like if after a fresh install or upgrade of xSP Storage Server if it is running:
This change that is made on the "Backup Server" service, because the program was upgraded and the Log On As setting on the "Backup Server" service was forced reset to "Local System" may have broken the connection, due to lack of permissions, between the Storage target that was defined prior in the xSP Storage Server Configuration Manager -> Storage tab, as that storage target may have required a specific user that you assigned to the "Backup Server" service "Log On As" prior, and now that is broken because the service is no longer using that user to gain permission to the storage target. The Storage target that was defined may require that specific user that you had been utilizing before for the Log On As setting for the "Backup Server" service, and your Storage target definitions as you recall are configured and listed in the xSP Storage Server Configuration Manager -> Storage tab screen, as seen below:
If in the Share Properties of your Windows Share, where the Storage device added via xSP Storage Server Configuration Manager -> Storage tab, has not been allowed Share and File permissions access to the target network share / network path for instance and that network share / network path location is not open to the world with "Everyone" rights, and one of your target storage target(s) that is configured in the "Storage" screen above, is a Windows network share, then the fact that the "Backup Server" was reset to default Log On As and is now using "Local System" as the Log On As setting, this is probably why it can't gain access to the folder to make the connection to allow backups to that storage target, since for one thing you are changing how the "Backup Server" service is now running as for the Log On As account property, and using for permissions to gain access to the target network storage location, versus how it was originally set up prior to the upgrade of the xSP Storage Server. It could also be because someone changed the password for the user that your service had been utilizing other than the Local System account, or deleted that user, or removed that user from the Administrators group. In most cases this issue is due to lack of permissions to authenticate to the target network share path (the Storage location that was configured via xSP Storage Server Configuration Manager -> Storage tab).
The resolution for this:
Please verify that the "Backup Service" on each of your xSP Storage Server systems, that has the xSP Storage Server application installed on it, is showing "Running" for the status and it has that service set to the same user that you had specified prior to the Storage Server upgrade, otherwise the storage target(s) that were configured previously in xSP Storage Server Configuration Manager, displayed in the screenshot above, where backups are pointing to as the target storage location, won't have the permission with Local System to get to that target folder (usually that is a network folder that is the target), and so because the Backup Service is what is attempting to get to that storage target and that storage target only allows specific users to get access to it, then it cannot access the target storage location and that is why backups, test connections, from the backup client fail.
Here is an example of how we had the Log On As setting on the "Backup Service" set to prior to upgrading the xSP Storage Server component, the "Log On As" setting is set to ".\xsptest", this is a local user account set up on the Windows Server that the xSP Storage Server is installed on, and that user is in the Local Administrators group, and that is the user that same username and password is in place on the Windows Share where our backup location is at, that user is assigned to both the share permissions and the file permissions for the target network storage path assigned as the "Storage" device in xSP Storage Server Configuration Manager -> Storage tab. Note the last column:
After setting the Log On As setting to the appropriate user that does have permission to that shared folder/target, right-click on the "Backup Server" service and restart it on all of your xSP Storage Server systems. If it fails to assign that user to the Log On As then verify your permissions for that user that you are attempting to assign and make sure they are in the Administrators group, make sure the password is set and you may have to change the password at that point on the account to set the Log On As setting. Here is an example of showing the 'lusrmgr' command, which is Windows Local Users and Groups Manager, available on all Windows systems, to verify that you have your non-Local System user, in our case "xsptest" user, in place, and if you need to you can set the a new password for that user or add it to the Administrators group with the following highlighted areas. This will be similar if done in "Active Directory Users and Computers". You will make sure to add this user to the target machine where the target network storage share / path is assigned so that the Backup Server service, now running under that special assigned user, can have full control access to that target path.
After verifying that the account is in place on the system where the xSP Storage Server is installed as well as on the system that the target storage network path is located, and after setting the Log On As setting of the "Backup Server" service to a particular user account, then after restarting the service again and make sure that the service shows "Running" for the status. Once the service shows "Running" for the status and is set to a non-Local System account for the Log On As setting, that is all that you should need to do, and then you can re-try the connections from the backup client to the xSP Storage Server by running a backup job that targets that Storage Server, or by doing a "Test connection" in the backup client's Device tab, and double-click on the xSP Device. If the problem is corrected then both of those items will work, including the completion of your backup job to that storage target on xSP Storage Server.
If the problem persists it is most likely due to permissions, since if your "Backup Server" service is assigned to a particular local Windows user account (view this using Control Panel -> Users, or you can run the command 'lusrmgr.msc' in Windows) or AD domain account it needs that same account in place with the same username and password on the local Windows user account / AD domain account. At that point simply verify your permissions and the account password is the same on the user account that you are attempting to run the "Backup Server" service on the xSP Storage Server's in question, and verify the same user is in place on the target network storage location for the Share and File properties of that network path location on the target device/computer, so that the user that you assigned to the "Backup Server" service Log On As property, in our example that is a local (non-domain) "xsptest" user, and that user is added with the same username and password to each of your target network storage path / share locations.