Trouble using credentials for backing up to network drive
Well, this problem is a constantly returning bad penny. I marked issue https://forum.acronis.com/comment/509708 as solved, but now having troubles again.
To summarize, I am specifying a network location on an Active Directory Domain as the destination for backups on all the workstations in the office. As the last post in that referenced topic indicates, I was finally able to accomplish this by creating a dedicated domain user just for backing up, and specifying: domain\username as the User Name, and using that user's domain password -- logged in as an Administrator.
That worked, sort of. Often it would give me "Connection failed", even with the correct credentials. Sometime it seemed to work after restarting the computer; sometimes I tried unmapping the non-Admin user from any samba maps; then sometimes it worked if the user re-mapped the mount. Sometime it would just work if I waited a few days. In short, there seemed to be no pattern as to when the connection would fail or when it would eventually start connecting. However, over time I got all the workstations to ultimately connect.
Now I'm stuck again. I had one user backing up to the network drive, but ATI didn't seem to be cleaning up old versions. So, I deleted the backup, and all files, and went to add a new backup. However, now it won't connect. I've tried all the trick I've done before, but this time nothing works.
I'd like to get this working short of uninstalling and reinstalling ATI 2020. One thing I'd like to try is resetting the credentials. When I select the remote target, it brings up a box that is pre-filled in with my previous attempt. How can I clear this out? Where is this kept? It's not in the Credential Manager. BTW - this is Windows 10.
Suggestions on getting the to work (again)?
Enchantech: I must confess, I'm not sure how Acronis authenticates. You certainly know better than I. I found the credential repository you mentioned in the registry and cleared that, but it didn't help. Regarding your question, "Do your client machines sign on to the AD server prior to the backup task running?" I don't really know what you're asking. The client machines are all Windows 10 and usually the users leave themselves logged in (AD) when they leave for the day. However, even if they log out, the backup-to-network task works on all other workstations.
All users are configured as standard users, not administrators, and the Acronis backups are configured using the domain administrator account, which is never left logged into the workstation other than for admin configurations like this. If your question is not related to users specifically, but to the machine itself, all workstations are domain members.
I've have confirmed that the id and password I am using on this computer in Acronis for network backup verifies with NTML_AUTH. The credentials are correct. Every other workstation in the office uses these credentials to successfully backup to the network device. I ALWAYS get "Connection failed" on this one workstation. I have confirmed in Control Panel > Programs and Features > Turn Windows features on or off, that SMB 1.0 is NOT enabled.
You wrote: "I would think that if the clients authenticated user is signed in to the AD then the backup should work. If the client user is not signed in or the TTL network session has expired then connection would fail and so would the backup task."
Not sure to which "authenticated user" you are referring. The workstation user's credentials are not the ones used in the backup. As per that referenced link, I have a designated domain user, whose credentials don't expire, just for doing backups. I've tried using the backup user's credentials logged in as both the workstations normal domain user and as the domain administrator to configure this new network target. I continue to get "Connection failed" when configuring a new backup to a domain member computer network destination.
As mentioned, other domain users need not be signed in for the Acronis network backup to work.
Tech,
So as I understand it your client machines all use the Domain Admin account to run the Acronis backup tasks. You have a single client that fails "Connection" and cannot run the task no matter what you try. All other clients perform the backups as scheduled by the configured task. Is this all correct?
When the True Image app was installed on the client machine that has this connection issue, was it installed as an Administrator?
Do you have access from this client to the Domain server using for example File Explorer? I assume that you do however, that connection is made via a standard user account to such users authenticated account on the server correct?
Have you tried signing out the standard user on this client from the Domain server then, running the backup task? I am wondering if this client is somehow hitting the "more than one network connection" restriction of Windows 10. If you can make connection with True Image with the user signed out and then run the task this should establish the connection as that of the Domain Admin. If True Image is somehow getting confused between the standard user account and that of the Domain Admin removing the standard user by sign out my solve the issue.
Enchantech wrote:Samba is the protocol that Linux and its variants use to communicate to Windows network shares. Windows network shares use the SMB protocol. Windows 10 uses SMB 3 specifically 3.1.1 as the strongest variant of the protocol.
If I understand this correctly, Samba is actually the Linux/UNIX program providing support for (among other things) a variant of the SMB protocol.
Patrick O'Keefe wrote:Enchantech wrote:Samba is the protocol that Linux and its variants use to communicate to Windows network shares. Windows network shares use the SMB protocol. Windows 10 uses SMB 3 specifically 3.1.1 as the strongest variant of the protocol.If I understand this correctly, Samba is actually the Linux/UNIX program providing support for (among other things) a variant of the SMB protocol.
As quoted directly from SAMBA.ORG:
" Samba is the standard Windows interoperability suite of programs for Linux and Unix."
As quoted from Wikipedia:
" Samba is a free software re-implementation of the SMB networking protocol, and was originally developed by Andrew Tridgell. Samba provides file and print services for various Microsoft Windows clients and can integrate with a Microsoft Windows Server domain, either as a Domain Controller or as a domain member. Wikipedia "
Whether program or protocol Samba provides the method which Linux/Unix use to communicate and work with Windows Domain servers and Windows SMB protocol.
Enchantech wrote:"So as I understand it your client machines all use the Domain Admin account to run the Acronis backup tasks. You have a single client that fails "Connection" and cannot run the task no matter what you try. All other clients perform the backups as scheduled by the configured task. Is this all correct?"
No, the client machines all use the same standard Domain account to backup, not a Domain Admin account. All other clients do backup successfully. This particular workstation used to back up successfully until I deleted and re-created one of the backups.
"When the True Image app was installed on the client machine that has this connection issue, was it installed as an Administrator?"
YES
"Do you have access from this client to the Domain server using for example File Explorer? I assume that you do however, that connection is made via a standard user account to such users authenticated account on the server correct?"
YES. This workstation, as the standard domain user, can access the ActiveDirectory/DomainController via File Explorer. It is also configured with Redirected Desktop so the Desktop, My Documents, Favorites, etc. reside on the AD/DC. It also maps a Samba Share from the NAS, which is also a domain member. The target for the Acronis network backups is on this same NAS.
"Have you tried signing out the standard user on this client from the Domain server then, running the backup task?"
YES
Now for the surprise: I tried one last time logging in as the standard user, running Acronis (and entering Admin credentials) and configuring the backup with the network target. Again, I got 'Connection Failed". At that moment I was called away from my desk for some period of time. When I returned about 20 or so minutes later (possibly longer), just for the heck of it, I clicked the "Try Again" button and this time it connected! The only difference between this test and all previous tests was the time delay in trying the connection.
I don't know if this time delay was the trick, or if it just happened to start working, as in previous workstations configs. I'll have an opportunity to test this theory as I have two other workstations that do not clean up previous version despite settings accordingly. I am going to completely remove Acronis from these workstations and configure from scratch in which case I expect to get the "Connection failed" status on one or both. I'll post results.
Tech OHPRS wrote:
Now for the surprise: I tried one last time logging in as the standard user, running Acronis (and entering Admin credentials) and configuring the backup with the network target. Again, I got 'Connection Failed". At that moment I was called away from my desk for some period of time. When I returned about 20 or so minutes later (possibly longer), just for the heck of it, I clicked the "Try Again" button and this time it connected! The only difference between this test and all previous tests was the time delay in trying the connection.
I don't know if this time delay was the trick, or if it just happened to start working, as in previous workstations configs. I'll have an opportunity to test this theory as I have two other workstations that do not clean up previous version despite settings accordingly. I am going to completely remove Acronis from these workstations and configure from scratch in which case I expect to get the "Connection failed" status on one or both. I'll post results.
I have had similar experience with a connection failed result and True Image. I have had the issue with a number of versions of app all the way back to 2016. What I have discovered is that the complexity of my small home network (no Domain server involved) is partly to blame. I will also say that TI 2020 is much better at handling my network system than any previous version. To that end I have found that there are times when being patient and giving the application time to resolve the location fixes things.
In addition to time I have found that I have much better success with connection when hostname/sharename are used rather IP/sharename. You now make mention of the use of an NAS device running I suspect a Linux/Unix variant and that this NAS is your target for TI backups. In my view that adds another level of complexity to your network and that supports my findings with connection failed errors and the slowness there is with resolving a network location.
For example I have a network that consists of a primary network that uses a subnet. Three of my computers have dual NIC's so I have connection to both the primary network and the subnet with those machines. All other computers (5 total) all connect via the primary network. The subnet hosts two of my three NAS devices. The third NAS that uses my primary network is a Freenas server box which hosts SAMBA/SMB shares. This device I have had issues with connection using the subnet as it refuses to connect reliably unless I have SMB1.0 enabled on my client machines. Since I have made the conscience decision not to have SMB 1.0 working on my machines, I have had to place this server in service on the primary network. In doing so it works happily as long as I use hostname/sharename and not IP/sharename. This makes absolutely no sense to me as I can login via web interface using IP Address without issue but not to an SMB share. All machines are Win 10 running the latest upgrades and fully updated. The Freenas server is running the latest release of 11.2 as well. So to remedy connection issues I have created Network Locations on my Windows 10 machines that point to the SMB shares on the server and select those locations under This PC in TI.
I realize this probably does not help you at all but thought you might somehow get some idea of what to try in your situation.
Enchantech, thanks for your feedback. I am using hostname/sharename, not IP/sharename. Furthermore, the NAS (Linux/Samba) is also an Active Directory domain member.
So, after further testing. Indeed, waiting a while does the trick. For both of the workstations for which I uninstalled and reinstalled ATI 2020, my "Connection Failed" during the initial configuration of the backup to the NAS. After waiting a bit (I've only tried 20 minutes or more -- no idea what the minimum time might be), and retrying, I connected successfully!
Sheesh! This one goes into my "Acronis Tips" folder. It's been a long and painful journey, but I now have another idiosyncrasy in my repertoire!
Tech OHPRS,
Well, I am glad to hear that you have the issue sorted. In all honesty I have never timed the wait period nor have I tried to however, thinking back to the last time I had to make an initial connection I know that I had to retry twice with probably about a 1 minute or so pause between them. So I am guessing somewhere between 3 and 5 minutes.
Once the connection is established it works as expected and I do not experience any further complications. I trust you will not either.
I have the ability to use Active Directory on my Freenas server but feel it is overkill in my home environment. If I had an office environment however, I certainly would venture down that path. :)