[SOLVED] NAS credentials issue when selecting "open location" in backup menu (build 20770)

In the list of backup, I click on the upside down caret of a system backup where the destination is a NAS, and select "open location" in the menu. Unexpectedly, a Windows security windows open asking fo the NAS credentials. When filled out, the operation fails anyway. Note that the backup is running fine to this location with the same credentials.
Something is amiss with the way 2020 stores NAS credentials, or pass them to Windows, etc.


- Se connecter pour poster des commentaires

This is still working ok for me to my Synology NAS when I click on Open Location from the task.
I use a user account that only exists on the NAS for the purpose of my ATI backups, it has no Windows account of the same name and I do not map any drive letters from the NAS in Windows.
- Se connecter pour poster des commentaires

@Patrick, yes correct. Windows explorer should open and show the backup location. The user can access the NAS backup location with the same credentials put into Acronis.
@Steve, so it looks like you don't see the same issue. I also have a Synology NAS and I use the same credentials for ATI as for Windows Explorer to access the NAS backup location. The set of NAS credentials are not NAS admin, but have full read/write to the entire share where the backup are stored.
When I tried to edit the credentials of the existing backup to try another set of NAS credentials (NAS admin account), I couldn't (failed to connect). I had to create a new backup task.
The problem still exists with the new backup task and a set of NAS admin credentials. The backup runs, and the open location displays the windows security "enter your network credentials". The default credentials are still the previous ones. I can switch to use the NAS admin credentials (still Windows security windows). When I use the NAS admin credentials, the access fails and ATI displays the error:
Event code: 0x006400D7+0x00640241+0x00040014+0x0000FFF0+0x800704C3
Can you guys replicate?
- Se connecter pour poster des commentaires

To work around the issue of not being able to edit the credentials, I used the old workaround:
Close down ATI
Delete the existing credentials in the registry under
Computer\HKEY_CURRENT_USER\Software\Acronis\Connections\smb\
Launch ATI and reenter the credentials
- Se connecter pour poster des commentaires

I think this may be a Windows limitation. A windows logon session (the account you've signed onto Windows with at present) can only have one authenticated session to the same remote device or share. For example...
If you have the share mapped (saved credentials) in Windows, that is one session. If you use the same credentials you mapped the share with on Windows for the NAS connection in Acronis, that still counts as the same 1 session.
But...
Once you launch Acronis and do anything with the task, it has just authenticated to the share first (session 1). If you then try to modify the credentials, that looks to be session #2 because Acronis True Image just accessed it with the first login information and the app is still active, keeping session #1 open... or if you have it mapped in Windows, it's definitely already in use, which is going to fail your new credentials for trying to authenticate from Windows with 2 different sets of credentials under the same logon session.
Clear as mud, right?
- Se connecter pour poster des commentaires

Bobbo_3C0X1 wrote:I think this may be a Windows limitation. A windows logon session (the account you've signed onto Windows with at present) can only have one authenticated session to the same remote device or share.
This would certainly be the problem if a connection already exists (with different credentials) between the user and the NAS. "User" is tricky, here, though. I did this display shortly after starting a backup task on my old test PC to a NAS.
PS C:\WINDOWS\system32> Get-SmbConnection
ServerName ShareName UserName Credential Dialect NumOpens
---------- --------- -------- ---------- ------- --------
mybooklive2 Private NCIX0001\Patrick MyBookLive2\Private 2.0.2 0
mybooklive2 Private NT AUTHORITY\SYSTEM MyBookLive2\Private 2.0.2 1
mybooklive2 Private NT AUTHORITY\SYSTEM NCIX0001\Private 2.0.2 0
(Sorry. The formatting gets messed up there.)
My local computer is "NCIX0001"; my local userid is "Patrick".
The NAS is "MyBookLive2"; the userid on the NAS is "Private".
Both my userid and NT AUTHORITY\SYSTEM have SMB connections with the NAS.
Both are using the same credentials.
I suspect that if either my userid or NT AUTHORITY had a connection to a share on that NAS using other credentials, the ATI connection would fail. (That's a guess. I really don't understand how this all fits together.)
BTW (and this really should be a topic of a different thread), after the backup has completed, the SMB connection between NT AUTHORITY\SYSTEM and MyBookLive2\Private remains active. I believe that allows any task running under NT AUTHORITY\SYSTEM to have access to the target share on that NAS with no further authentication. That sure looks like a security flaw to me. Perhaps this would not be a problem if this NAS supported SMB 3.
- Se connecter pour poster des commentaires

Steve Smith wrote:This is still working ok for me to my Synology NAS when I click on Open Location from the task.
I use a user account that only exists on the NAS for the purpose of my ATI backups, it has no Windows account of the same name and I do not map any drive letters from the NAS in Windows.
+1 here. I have different user name and password to my Windows one so I do not have any issues. Also, when I connect to NAS from Windows I use the former password and user name. So far I have not had any issues, even on the one PC (which is rarely live) that has mapped drive on the NAS (again using the NAS specific user name and password). Under these conditions I would not expect to see a problem.
Ian
- Se connecter pour poster des commentaires

Pat,
In your example of connections:
mybooklive2 Private NCIX0001\Patrick MyBookLive2\Private 2.0.2 0 is your Windows user access to the share via a Windows process such as Explorer. The final 0 indicates the connection is closed.
mybooklive2 Private NT AUTHORITY\SYSTEM NCIX0001\Private 2.0.2 0 is your ATI connection run at the Windows System Admin level to the share.
mybooklive2 Private NT AUTHORITY\SYSTEM MyBookLive2\Private 2.0.2 1 is your Windows System Admin level to the share which was opened by a Windows process (Explorer). The final 1 indicates the connection is still open.
ATI is successfully closing the connection when it is no longer needed whereas Windows System Admin does not.
- Se connecter pour poster des commentaires

OK. With all your tips and experience, I discovered I had multiple hidden, sporadic processes accessing the NAS and that could explain the part of my problem where entering the credentials upon "open location" was resulting in failure, since it was possible that the same interactive Windows user was trying to use different NAS credentials at the same time.
Since ATI is using different users for the backup task and the UI functions, the backups were still going through in interactive mode.
I have opened and closed another thread about the backup menu and the recovery tab not working any longer. I solved that by deleting the existing archive database and running the backup to rebuild it. Incidentally, that solved the "open location issue" at the same time.
- Se connecter pour poster des commentaires

In case this helps. I deleted any mapped connections to my NAS and then I went into Windows Credential Manager and deleted any login data to the NAS. Next I clicked on OPEN LOCATION in ATI and it prompted me for my local desktop password. I entered it and it opened fine. Now I am going to try to map drives again and see if it still fails.
- Se connecter pour poster des commentaires

I too have issues. When recovering using a file on my Synology NAS TrueImage 2020 will not accept my normal account credentials but will accept the admin account. But then I have Synology telling me to disable the admin account to prevent brute force ransomware attacks.
Let's have a definitive answer from Acronis. This has been rumbling on since at least 2016.
- Se connecter pour poster des commentaires