Backup to NAS usually fails - inaccessable
4 of the last 6 attempts to backup to a NAS have failed with "The network share is inaccessible". The share is, in fact, accessible. The physical drive may have shut off by a power saving option and needs to spin up, but the NAS is always accessible.
I haven't been keeping track, but it looks like scheduled backups fail but manually started backups succeed. The messages in the ti_demon log don't help much:
8/28/2019 11:31:25 AM: Error 0xb042b: The network share is inaccessible.
8/28/2019 11:31:25 AM: Error 0x13c0005: Operation has completed with errors.
Maybe it's time I download Steve's script and see what the new log says.
BTW, I had retry options of 5 times, 30 seconds apart (the default, I think) and have changed it to 2 times, 2 minutes apart. I don't see any indication a retry was tried so I doubt that will help.
I had the same issue on one computer and a combination of solutions fixed it apparently.
a) the backup was set up with NAS user credentials different from the NAS user credentials of the main windows user of the computer. It is possible that as the computer woke up to run the task, the main computer user NAS credentials were still used to access the NAS and ATI services were denied to access the NAS with different credentials (on WIndows, a network computer can normally be accessed with only one set of credentials per user session). On an Ethernet wired computer, the backups were setup by the main computer user with his NAS credentials and the backups are running fine.
b) the external wireless adapter is apparently slower to connect than the internal one which was disabled. I put an external one which is faster. It is possible that ATI was trying to access before the wireless was connected. Although, that would resolve itself during the retries if it was only an issue of delay. Nevertheless, I have reenabled the internal wireless.
All these are presumptions of issues and solutions, but the problem disappeared on that computer. I will continue testing with the other laptops.
Pat L wrote:I had the same issue on one computer and a combination of solutions fixed it apparently.
a) the backup was set up with NAS user credentials different from the NAS user credentials of the main windows user of the computer. It is possible that as the computer woke up to run the task, the main computer user NAS credentials were still used to access the NAS and ATI services were denied to access the NAS with different credentials (on WIndows, a network computer can normally be accessed with only one set of credentials per user session). On an Ethernet wired computer, the backups were setup by the main computer user with his NAS credentials and the backups are running fine.
In this case, the computer - a laptop - does not wake up to run the task. The task is scheduled to run at a time the laptop is powered off. Many hours later, I turn on the laptop and log on. The task is defined to start a missed backup 10 minutes after startup. That task (which will run in the background whether started by schedule, but the restart timer, or by my manually requesting it) should be using the only credentials that have been provided for the task.
Are you saying that those credentials are somehow incorrect when the task is invoked by the restart process?
When you log on to your computer and see the backup fail, is the windows user account your are using connected to the NAS for any reason? For example, accessing SMB shares for file access?
Is the Acronis backup task using the same credentials to access the NAS or some other one?
For example User A is logging onto Windows and access the NAS using credentials X.
The backup task has been set up to access the NAS with credentials Y.
If Y is different than X, the scheduled backup fails. If Y is the same as X, the scheduled backup succeeds.
Note that the situation might be different with an interactive backup run (when the user triggers the task, not the scheduler).
Pat L wrote:When you log on to your computer and see the backup fail, is the windows user account your are using connected to the NAS for any reason? For example, accessing SMB shares for file access?
Not that I know of. This NAS is used only for ATI backups - some SMB, some FTP - and for some scripted WinSCP FTP copies. I should have no SMB connection with the NAS.
Pat L wrote:Is the Acronis backup task using the same credentials to access the NAS or some other one?
For example User A is logging onto Windows and access the NAS using credentials X.
The backup task has been set up to access the NAS with credentials Y.
If Y is different than X, the scheduled backup fails. If Y is the same as X, the scheduled backup succeeds.
Note that the situation might be different with an interactive backup run (when the user triggers the task, not the scheduler).
There is only one set of credentials - one userid and password - defined on the NAS (other than the admin account). Any access to the NAS would use the same credentials.
OK. Thanks. I am still investigating some NAS user credential issues.
But pursuing for the path of conflicting credentials, the Windows user has not accessed the NAS by any means (for example, just browsing to it to check the backups :-)?
Pat,
In reading this thread do I understand correctly that you have a single NAS target to which you have a PC or PC's with different admin users whom have different NAS user credentials. Issue, when a different user is logged onto the PC other than the user that created the backup task and that scheduled task created by another user is run the task fails with the "network share is inaccessible" error?
Enchantech,
Correct. I don't know if the factor here is who created the backup or which NAS credentials are used. I have each Windows users (all admins, and all main users of a different PC) have a separate and individual set of NAS credential. I ran ATI 2019 by created the backups under the main user in Windows and use their NAS credentials.
It was the first time I did it differently and the backups failed, while the one computer that is mine where I kept the same approach is working fine.
I noticed I had some other issues with NAS credentials, and I opened a thread on it (cannot use the open location command of the backup menu).
Pat,
I think this may be expected behavior. I myself had issues with NAS logon and finally solved the issue after spending an entire day working on it.
Your NAS being a Synology device is not the same as where my problems were so I doubt you have the same problem and others here that use the Synology seemingly do not have your problem however they may not be attempting to use these devices in a like manner.
I did some experimenting and captured some screenshots I am posting below to show how connections are working for me now that I have my issue fixed. Not sure that they will help you but, they do show how connections are used on the client and server sides of a SAMBA SMB computing session.
My problem turned out to be a Windows permission error on the SMB share where I had read permissions but not write permissions to the share. That was solved by changing the access level of the user on the NAS device itself. Basically I had to have the user account on the NAS nested under the NAS root rather than under another Group.
I have added a description of each screenshot below each one so that you will know what you're looking at.
Image above shows a PS session where I ran get-smbconnection during the testing sequence. At the top the command returned nothing as no connections were established. The second time I ran the command was after I had opened an Explorer window to the NAS device. Notice it shows 2 Open connections. One for the client and one for the server in this case. Also please note that the Windows user connections in these examples use the same credentials to access the SMB share that are used by TI.
The third time the get command was run was after closing Explorer and opening TI 2020. Notice that there are now two NAS devices showing. I actually have three NAS devices but I only have backups from TI to the two devices shown that being the one at the IP Address and the other to the TNAS entry. Notice that the first line shows my NAS user account connection. The second line shows my Windows connection to the share. The third line shows the second NAS device but no open connection exists. The two open connections to the IP Address show that line 1 is an open connection to the backup location on the share that is selected by default when TI is opened. Line 2 is and open connection from the client machine and shows 2 Open which includes line 1 client and the server connection.
The forth time the get command was run shows that now my Windows user has 6 open connections. Those are the previous connections plus, a different task that I have selected in TI. So even though the TNAS connection is no longer shown the client still shows an open connection.
The fifth time the get command was run shows that 8 open connections now exist because I have now selected a third backup task to the device in TI. The command shows the total connections of the user and the current selected shared file connection.
The image above shows the result of my use of the cls command to clear the PS screen and then the get-smbconnection run yet again after I closed TI and then opened the SMB share using Explorer. Notice that the Open count still shows 8 for the user so all previous TI connections to the share for both client and server sides. Note that this screen shows that I have selected the NAS server share folder in Explorer but not the file share. If I further select the file share then another entry will appear showing the NAS user connection and the total open connections will increase yet again.
Windows will close open connections after a default 15 minutes has elapsed after all open connections are closed unless access is once again made to the share. This can occur if another app opens a share file or if you have a mapped drive to or as the share then the connection will remain open throughout the entire computing session. This behavior of mapped drives is why I do not use them preferring to use hostname instead. In my examples here you will notice IP Address is used as a hostname not as a mapped location.
Thank you Enchantech. Your process of tracking connections got me going and I found out there was another set of processes (outside ATI and Windows Explorer) that were still accessing the NAS in the background intermittently. The good thing is that these processes were clean in the way they opened and closed connections. These indexing and synching processes were happening often enough, and the share I use for backup was sometimes included. Apparently, they all used the NAS credentials stored in the Windows credential manager. So that it could explain part some behavior of the ATI UI as it was possible that the same Microsoft user was trying to access the same share with different credentials set in different apps at the same time, although the backup task (using the system user) was able to run.
Along the way I bumped into another UI issue for which I will open a new thread.
I will continue investigating the ability to use ATI-specific NAS credentials for scheduled backup.
Pat,
Glad to have helped. With work you should be able to get it all sorted. :)