Another NAS-related problem
I've just run into another NAS-related problem. This time NAS as ther source rather than destination of a backup. I don't have a very good understanding of the problem so the following description is probably not quite accurate.
I use a NAS to hold files I access from 2 PCs and a laptop. These files are in a public share mapped to a drive letter in each of the Windows. On one of the PCs I take an Acronis ATI backup of this share with the destination on a USB-attached external drive. (This is sort of the reverse of most NAS scenarios: the NAS is the source rather than destination of the backups.) These daily backups worked for at least one day following my upgrade to ATI 2017, but started failing as soon as I started testing the recent NAS authentication problem. In the Acronis log I see message=Cannot find the files or folders selected for the backup. This failure has been happening for several days, and Acronis retries a number of times each day. Lots of failures.
I could not find any way to display the list of files and folders backed up so I decided I'd better rebuild the source definition. And, of course, I immediately ran into the authentication problem. So it happens for both source and destination on NAS. Windows would not let me unmap the drive because it said the drive was in use by an application - probably Acroinis since I originally set up the backup referring to the drive number. I got around the problem by defining an "alias" in the Windows host file, but I don't consider that a good solution.
Except when I'm testing, I take no Acronis backups to any NAS device on my "primary" PC so I suspect I can delete all Acronis SMB credentials registry records and get back to my original backup definition, but I probably won't be able to test that until this weekend.
Both the Windows restriction requiring only a single set network credentials for each NAS/user pair, and the Acronis bug resulting from Acronis developers forgetting about that restriction are real pains in the posterior.

- Log in to post comments

Defining an alias in the Windows hosts file circumvented the proble.
- Log in to post comments