NAS drive not authenticating

OK, I am on Windows 10 Pro, version 1607, 64 bit, including the cumulative update KB3194496. The version is: 10.0.14393.

Update: also for me stopping and starting the workstation service temporarily fixes the issue. I will try out a few more things suggested above, as soon as the backups that I now was able to start will finish :-)

Hi TheCreator,

Thanks for the detail information, specially on Windows 10 insider. 

in my case, I have no problem accessing any mapped drives to my NAS or directly via UNC path from any other program than ATI.

I for one am glad I do not use mapped drives.  Has saved me further headaches I'm sure!

I also do not use mapped drives with my Synology NAS and have not had any problems since updating to build 5554 along with having the latest Windows 10 AU and top-up updates installed (10 14393).

Win 10 x64 Pro v1607 (14393.222) and Acronis 2017 5554...

I just created a new VM for testing.  I did NOT have a network drive mapped in Windows to the VM as a drive letter.  I create a new backup in Acronis and pick the NAS as a destination using  

browse >>> network >>> NAS >>> NAS folder

I'm prompted for credentials, I enter them and the test says successful.  

However, before I do anything else, as a test, I then decide to try another NAS folder that I have setup to only allow another NAS account.  I'm already in the NAS and exploring with Acronis at this point.   I expand another folder on the NAS that uses a different set of credentials and click on the "edit credentials" button and enter those and it fails and fails and fails and fails.  I press "cancel" and it taks me back to the "backup destination" page where I then click on

browse >>> network >>> NAS >>> NAS Folder

and pick the folder that just previously failed, "edit credentials" and enter the new user account and credentials and this time it connects.

I can repeat the behavior back and fort between the 2 shares on the NAS with using different credentials this way.  Basically, it's just a matter of trying it once, cancelling and then going back in and trying again and all is well.

Again though, I don't have any mapped drive in Windows.  Is it a bug?  I don't think so  because of the Windows limitation of Windows only allowing one SMB connection under a Windows profile to a remote SMB share on a single NAS device at a time.  I think the behavior is just a matter of the Windows session being "locked in" when the first connection is made and that becomes unlocked, by cancelling and going back in and entering the new/different credentials before any connection attempts are made.

I will test with a mapped drive to the NAS and then repeating and see if it makes any difference. 

OK, so with a mapped drive to the NAS, I can start the same process as I just did above and it starts off the same.  However, when cancelling my original NAS folder selection and going back in to select the other NAS share fodler, I notice that Acronis thinks for a second and automatically authenticates using the previously selected share (actually it's the same logon as used for the mapped drive) so the second test fails and continues to do so over and over and over again.  

I close out of Acronis, I disconnect the mapped drive and open Acronis and repeat my test.  This time, when I expand the network option and select the NAS, it does not try to authenticate automatically.  I pick my second NAS folder, using the second set of credentials and enter them and this time it is successful (just like the first test above).

So, I would say that Windows is somehow passing on the mapped drive first in the Windows explorer session and holding onto it somewhere.  If using the exact same credentials for the mapped drive and the desired share on the NAS, I have no issue connecting to a second or even third share in Acronis... AS LONG AS the credentials are exactly the same as those provided for the mapped share.  But, if there is a mapped drive already and then I attempt to connect to a different NAS share in Acronis (one using different credentials), then that is where the problem seems to arrive.

Stopping and starting the workstation service will kill any existing network share credentials stored in the session so this makes sense to me as to why it temporarily works.  

The suggested work-a-round above (if using a mapped drive and the credentials are EXACTLY the same) should allow one to connect to the NAS in a second location on the NAS as long as the account, password, and connection UNC patch are EXACTLY the same.  Otherwise, if the mapped drive is authenticated differently (via DNS name instead of IP, or some other anomally) this will be a problem. 

For me, this behavior seems to be exactly correct as I would expect it to be based on Windows limitations of a single session to a remote SMB device per Windows logon.

Very interesting and thank you for working this in detail. This could indeed explain several things and I will test this myself (will be a few days as I am away o business right now). It is possible that I am connecting to the 20TB FreeNAS in at least two different ways in one session. But a few questions still come to mind: I also have this problem with the WD MyCloud of which I am sure I only connect to using a single user/pswd and 2. why did this not happen with 2016? Or does it and is it a result of the new Windows build being more strict? (I have not yet try to roll back to 2016 under the new build).

Wim,

In my opinion Windows stricter, as you put it, securtiy policies are exactly the reason for the situation.  Do some experimenting based on the contents of this thread and see if things improve.  I am betting they will!

I also agree with Bobbo that connectivity and authentication are working properly as designed for Windows 10 and Acronis 2017 version 5554.

All,

I am currently in the UK visiting my wife's family...limited connectivity and unable to connect to my NAS....so I am unable to run any tests.  Thanks to Bobbo for his efforts.

A couple of recommendations for those who cannot get ATI 2017 to log onto their NAS:

Download the Log File viewer and take a look at the install log and see if there are any error messages relating to NAS...most likely not, but worth a look.

https://forum.acronis.com/forum/115626

If you decide to perform a "clean install" then download the cleanup utility and follow the process in the link below:

https://kb.acronis.com/content/48668

Also, log into your account and download the full install file...and run the checksum program to make sure the download is not corrupted.

I have been following this thread (via e-mail) with great interest...

Bobbo, Enchantech,

So the thing left (for me) to explain is the issue on the WDMycloud that only has a single authentication set so it should / can not suffer from any of this. Nevertheless, Bobbo's investigation and explanation are very compelling that this is a feature rather than bug. I will test the FreeNAS system with a single set to mapped drives and folders to confirm, and will reset the WD again cleanly to see if some stranded connection is teasing me. All this a few days from now and I'll let you know. Many thanks again for your help, much appreciated!

Hi all,

Bobbo, thanks a lot for taking the time testing different scenarios with this NAS issue. 

This all make sense, but what we should keep in mind is that Acronis needs to work this out with Microsoft and find an acceptable solution.  The fact of the matter is that this was working before and it shouldn't be a requirement not to have any mapped drive in order to be able to use a NAS device as a backup destination.

In my case, at least following recommendations in this thread, by stopping and restarting the "Workstation" service allowed me to modify my backup profile and make the changes I needed, obviously this action disconnected any mapped drives not only to my NAS which Windows automatically reconnected once I open the mapped drives in Windows Explorer.

I will continue to monitor the thread and hopefully an official solution form Acronis will show up soon.

Everyone posting here:  Make sure that you have the latest version of Windows 10 ie. Windiws 10 Anniversary update 1607 version 14393.222 and Acronis True Image 2017 version 5554 installed.

You can check your Windows 10 version by left clicking the Windows Start button, select Run and type winver, click on Ok.

Keep in mind that if you are using a Microsoft Account to logon to your Windows 10 PC this may complicate matters as Microsoft Accounts are viewed as Domain accounts by SAMBA.  Domain accounts require additional authentication that can be set in Windows Credentials Manager if necessary.

Enchantech wrote:

Everyone posting here:  Make sure that you have the latest version of Windows 10 ie. Windiws 10 Anniversary update 1607 version 14393.222 and Acronis True Image 2017 version 5554 installed.

You can check your Windows 10 version by left clicking the Windows Start button, select Run and type winver, click on Ok.

Keep in mind that if you are using a Microsoft Account to logon to your Windows 10 PC this may complicate matters as Microsoft Accounts are viewed as Domain accounts by SAMBA.  Domain accounts require additional authentication that can be set in Windows Credentials Manager if necessary.

Hi Enchantech,

My configuration is exactly what you have suggested here, including loging with a MS account since Windows 10 was released, and still I am having this issue with ATI and the credentials reported in this thread.  I have been using this NAS for years now with mapped drives and UNC path and never had a problem accessing it from Windows or any other programs I use, only now with ATI 2017.

Edhy,

I understand your position however, Micrososft, in the interest of Security, has changed the way in which what is considered Remote Connection is handled from both a conectivity and authentication stand point.

If you’re using a Micorsoft Account (MSA) to sign into Windows 10, you may also need to create a domain user account with proper access permissions configured in Samba or Windows Shared Folders on the remote server for authentication purpose, as Windows 10 may assume those logging in with MSA as domain users and requires higher trust level for security.

The solution is to create a local user that had the same username with Microsoft Account used to sign onto Windows 10. In Windows, you can use Control Panel or PC Settings app to create a new local user account, while in Linux, uses useradd, passwd, and usermod to create the local user account or your management console, set its password and add it to the user groups which has the access rights in Samba.

Once you added the user account in remote server to connect to, time to add the user credentials for the network share to your system. To do so:

1. Open the Advanced Windows menu by left clicking the Start button and select Control Panel.
2. Go to User Accounts.
3. Click or tap on Manage Windows Credentials. Or, go to Credentials Manager then Windows Credentials tab.
4. Click or tap on Add a Windows credential.
5. Enter the remote computer name as the Internet or network address, and then enter the user name and password to your MSA account created on the remote server.
6. Hit OK when done.

When I setup Windows 10, I always start with a local account... I want to have that local access no matter what I do. This basically does what Enchantech is mentioning above as it keeps the old local account credentials stored as I eventually caved and merged it to a Microsoft account.  Funny thing is, sometimes, I can authenticate from another computer to a test share on my PC using either the Microsoft account credentials, or the original local account credentials - it varies with success though. 

As for my NAS connections - these are completely different accounts than what I'm logging into Windows with - I never try to make them the same because I don't want Windows, or the NAS, to ever try and confuse the 2 accounts (not sure how or why they can/do, but it happens so I just keep them different so that I always know which account is being used when I try to authenticate).  

I do use the same NAS account for my NAS media shares and my NAS backup shares for simplicity.  This is due to the Windows limitation of one remote session per SMB device at a time.  However, I don't map any drives in Windows with a drive letter.  Instead, I connect to the share via Windows File Explorer >>> network >>> mynas >>> nas share.  When prompted if I want to save credentials from within Windows, I say "yes" so that they get saved to Window s Credential Manager and I don't have to enter the credentials again when I navigate to the NAS under Windows File Explorer >>> network >>> mynas >>> nas share, since I want my NAS media to always be accessible to me from within Windows.  

I used to be more security conscientious and tried to keep my NAS media shares and NAS backup shares separte.  However, it became too troublesome with the Windows limitation of only being able to use one remote logon to a single remote device SMB connection.  So, when I setup my backups to my NAS in Acronis, I also use the exact same credentials in Acronis that I saved in Windows credential manager for the NAS media shares (File Explorer >>> network >>> mynas >>> nas share).

*** For those that are still having issues with 2017...

- Have you gone into the registry to verify what Acronis has listed for the SMB shares of your NAS?  

HKEY_CURRENT_USER\Software\Acronis\Connections\smb\<NAS name or ip>\<SMB share name>

- Are they all listed via the NAS DNS name or all via the NAS IP address only (no mixing and matching with some using IP and some using the name)?  

- Then, when you click on each of those shares, does it show the same username (exactly for each instance - all lower case or all uppercase)?  

- And does the encrypted version of the password match for each instance of the listed shares as well?  

Assuming the answer to all of these is YES, if you then go into control panel >>> credential manger >>> windows credentials, can you see you NAS saved credentials there too and is it also listed the same way as Acronis (using either the IP or the NAS DNS name, but so that whatever is in the Acronis NAS SMB registry settings matches how the credentials are stored in Windows credential manager).

I don't know if these are the answers and it doesn't explain why 2016 may have been more forgiving, but it's how I've always setup credentials in Acronis and has allowed me to use NAS connections througout 2015, 2016 and now 2017 without issue (other than the occassional bugs). 

I have this problem on two windows 7 machine, one home and one professional.

Hi Darren,

What version and build number of ATI are you using on these Windows 7 machines?

Ah yes sorry it's build 5554

Darren, is the issue on both machines happening when connecting to the same NAS, or is it an issue with one machine trying to connect to another share on the other machine?  

Hi Darren,

Thanks for the confirmation on the ATI version, it is the same version I have, which means that the problem is not really related to Windows 10 and since it was working for me before build 5554, ATI should have a closer look at this issue.

Yes both machines to same nas. Worked on older versions of ati and won't work either direct or via a drive mapping. Nas is a dns-320.

The DLink DNS 320 product has been phased out and may no longer be compatible with current Windows OS Security.  You might see if there is a firmware update available for the deivce, if so updating may get it to work.

So my nas the problem now then.  It works totally OK for everything else and the older versions of ati so this will now be ignored as an issue or for investigation even though it is Windows 7 machines that have not been patched since sp1 was installed oh and also I'll test with my windows 10 machine later. 

My nas is latest firmware

Darren Hughes wrote:

Yes both machines to same nas. Worked on older versions of ati and won't work either direct or via a drive mapping. Nas is a dns-320.

Hi Darren Hughes,

The latest Firmware for that Unit is Security Patch Firmware (2.05.B10)   Dated: 07/18/16

What Windows 10 Builds do you have currently installed?

Darren,

What I am suggesting here is this, Microsoft still supports Windows 7 meaing that Secutiry Updates are developed and applied on a monthly basis.  The latest update occured on Tuesday September 13 2016.  The next will occur on October 11 2016.

The vulnerability I have mentioned previously in this thread of malicious code execution run from a remote server was addressed in the September Patch Tuesday, Setember 13, 2016 for all supported Microsoft products.

There is 1 specific update to Windows OS to address the OS itself for this vulnerability. That update is 3178467.  Also updated was SMBv1 with update 3185879.  In addition IE was updated for the vunerablilty as well with update 3183038.

Anyone or all of these updates, especially in my opinion the SMBv1 update, possibly contributed to your issue.  So, if your NAS device does have the latest frimware applied then I would contact DLink and ask about any known issues with these Micorsoft Security patches and those devices.

A run down of the Security patch of Sept. 13 2016 can be found at the link below:

https://technet.microsoft.com/en-us/library/security/ms16-sep.aspx?tdui…)()

Same issue.  All my backups from my NAS are now broken... hours of time to download to the cloud.   Way to go Acronis.

Any idea how to sort this?  It looks like I can connect with IP + path, but host name+path will not authenticate.

Host name + path connection problems are most likely DNS server issues.  Check to make sure your DNS server addresses have not changed for some reason and that they can be reached.  If your DNS servers are provided by your ISP you should contact them in regards to possible issues on their side that are causing issue.

I'm not spending any more time on this. Two days doing updates and patches to these to bring up to date and nothing working.

Windows 10 anniversary update ion !y third machine s interesting. This was upgraded from 2014 with an existing backup to my nas which works fine. However I cannot set up a new backup to the same location without the credentials failing.

I'm reverting back to 2014 which works just fine and put this one down to bad experience...

I'm not spending any more time on this. Two days doing updates and patches to these to bring up to date and nothing working.

Windows 10 anniversary update on my third machine s interesting. This was upgraded from 2014 with an existing backup to my nas which works fine. However I cannot set up a new backup to the same location without the credentials failing.

I'm reverting back to 2014 which works just fine and put this one down to bad experience...

Thanks for the suggestion.

DNS is fine and on my router. I can get to the locations just fine from Windows Explorer.  This worked fine till I upgraded to 2017... Guess I will try to switch back unless these fools at Acronis can tell me how to fix.  I'm really hacked off that I have to waste time on this.  I guess the moral is never upgrade till you have no choice.

Enchantech wrote:

Everyone posting here:  Make sure that you have the latest version of Windows 10 ie. Windiws 10 Anniversary update 1607 version 14393.222 and Acronis True Image 2017 version 5554 installed. ...

Just a side (mostly off-topic) comment.  There is a fairly serious bug in the Windows 10 Cumulative Update KB3194496 - the update required to get to 14393.222 - that puts some users in an installation loop.  The next cumulative update -  KB3197356 (14393.223) - supposedly fixes the installation problem.  It is available by special download now and will be part of the regulare update process soon.   KB3194496 was released just a couple days ago so not all Win10 users may be at  14393.222 yet .  If you aren't at that level yet, and Windows version 14393.222 is really needed to address this Acronis problem, you should probably download KB3197356.  (There is apparently some special installation procedure required until it's available as part of the regular Windows update process.)

Patrick O'Keefe wrote:

Enchantech wrote:

Everyone posting here:  Make sure that you have the latest version of Windows 10 ie. Windiws 10 Anniversary update 1607 version 14393.222 and Acronis True Image 2017 version 5554 installed. ...

Just a side (mostly off-topic) comment.  There is a fairly serious bug in the Windows 10 Cumulative Update KB3194496 - the update required to get to 14393.222 - that puts some users in an installation loop.  The next cumulative update -  KB3197356 (14393.223) - supposedly fixes the installation problem.  It is available by special download now and will be part of the regulare update process soon.   KB3194496 was released just a couple days ago so not all Win10 users may be at  14393.222 yet .  If you aren't at that level yet, and Windows version 14393.222 is really needed to address this Acronis problem, you should probably download KB3197356.  (There is apparently some special installation procedure required until it's available as part of the regular Windows update process.)

I'd like to note that during my tests my VM was at 14393.222 as well (as noted in my original post) Although, I didn't have issues before that either.

Edhy Rijo wrote:

Hi Darren,

Thanks for the confirmation on the ATI version, it is the same version I have, which means that the problem is not really related to Windows 10 and since it was working for me before build 5554, ATI should have a closer look at this issue.

Based on this logic, it wouldn't be working for me or Enchantec either, but it is working for us.  I'm not saying it isn't an Acronis issue, but we can't say it isn't a Windows issue either since the constant is we're all using Acronis 2017 5554, but we all have very different configurations/settings in our OS and different types of hardware (both on the PC and NAS side). 

I've been trying to follow this thread but am having trouble telling if I'm going to be effected when I install ATI 2017.

I have 2 PCs running Win 10 at 10.0.14393.222 and a laptop running a slightly earlier version.  (I'm not sure what level.)  All currently have ATI 2016.  And I have only local Windows accounts on all 3 computers.

All 3 computers access files on a NAS - pulic shares only - as a mapped drive .  The 2 PCs backup to local external drives; the laptop backs up to a (public) share on the NAS.  The laptop's backups are not in the same share as the other NAS-resident data so I don't really need to have that share mapped, but I'm pretty sure it is mapped.  (All 3 computers also do an occassional FTP backup to a private share but only ATI knows about that share.  No SMB.  I'm pretty sure it doesn't figure into this discussion.)

Does this problem raise its ugly head if only public shares are used?  Obviously there will be no change of credentials involved.

Patrick,

Honestly, I'm not sure.  I just did some more testing.  I can repeat the issue over and over when I have a mapped network drive to the NAS and then try to create a new backup to one of the NAS shares that use the same credentials.  After I drop the mapped networked drive and go back into Acronis, then I can select it as a source using the browse >>> network >>> NAS method and all is well.  Once it's configured and working, as long as I leave the destination alone in Acronis, I can go back into Windows and map the drive again, and everything seems to work fine from that point on.  Perhaps this is the work-a-round for now. 

I hadn't even tried using a public share in Acronis or as a mapped drive from Acronis until just now. In my case, using public actually seemed to clear the problem for me, but it didn't.  I mapped a driver letter to the public share.  I then went into Acronis expecting to not be able to select the public share as the destination when using the browse >>> network >>> NAS method, but it worked!  Interesting.  So then I map another drive to the same non-public share that I've been using to test with and go back into acronis and change the destination expecting that not to work since it hasn't the entire time, but then it does too!  Then, I drop the public mapped drive and try again - still working.  

So, I reboot the system, but I've left the mapped drive of the non-public folder and no longer have the public folder as a mapped drive. Upon reboot, testing with just the non-public (authenticated) mapped drive again, I have the same behavior where I can not authenticate to the same share in Acronis.  At this point, mapping the the public share didn't help either, so I must have gotten lucky the first time.

Ultimately, for me, dropping all mapped drives first, then going into Acronis and picking the destination on the NAS seems to be the consitent working option. Once the source is selected and the backup is saved/run, it's set and forget.  I can then go and map a network drive and run backups to the NAS without any trouble. This is a work-a-round, but seems to allow one to create the NAS backup and successfully authenticate and then go back an map the network drives.  Once it's done, everything works fine in Acronis and in Windows, even if there are mapped drives (even public ones).

Perhaps this is an Acronis bug since it only seems to be a problem with the mapped drive being active when attempting to select the NAS destination... I'm not sure. If others could test by dropping the mapped drives, setting up their NAS backup, mapping the drives again and then leaving things alone and running the backups manually, does that work for you too?

Patrick,

In my opinion public shares are a no go in Windows 10.  I have seen references to some claiming to have no problem in using them with Windows 10 however, I believe that to be true prior to the security update of Sept. 13, 2016.  SMB does enter into the equation as it is the SMB that works with SAMBA to make it all work.  I believe that Windows 10 default is to use SMB3 with SAMBA.  In the early beta testing of Windows 10 after the release the first 10586 version network discovery of SAMBA servers became broken.  Devices running SAMBA cold not be seen in Windows and connected to by the usual means of File Explorer.  That problem was ermedied some months later when the official Windows 10 was released.

During this time period of the Win 10 beta an offered remedy was to enable SMB1 and SMB2 on machines which would fix the discovery problem but doing so brought with it known security risks.  I think that the security risks that existed in SMB1 and SMB2 were addressed in the latest Sept. security update and the Guest Account vulnerability with those version was fixed and in doing so may well have broken connectivity that used to work for users and now does not!  In my way of thinking if your PC and devices adhere to the SMB3 standard and you have Authenticated accounts setup correctly then you are not affected by the changes.  If one of the three are not true then you may well be impacted. 

I am confident we will learn more as time passes about all of this.  In the mean time make sure all your hadrware is up to date and Windows itself and if it does not work then short of submitting problem reports and checking with other device manufacturers about the issue they may have or know of for your device, thers is not much else you can do at this point.

Enchantech wrote:

Patrick,

In my opinion public shares are a no go in Windows 10.  I have seen references to some claiming to have no problem in using them with Windows 10 however, I believe that to be true prior to the security update of Sept. 13, 2016.  SMB does enter into the equation as it is the SMB that works with SAMBA to make it all work.  I believe that Windows 10 default is to use SMB3 with SAMBA.  In the early beta testing of Windows 10 after the release the first 10586 version network discovery of SAMBA servers became broken.  Devices running SAMBA cold not be seen in Windows and connected to by the usual means of File Explorer.  That problem was ermedied some months later when the official Windows 10 was released.

I can't argue on any technical level, but I've been on Win 10 for over a year, on the AU for over a month, at 10.0.14393.222  for a couple days, and have had no trouble with public shares.  I did strucggle a bit recently - probably after the AU - until I discovered I had to use the "Private" network profile (which I think is equivalent to setting “Make this PC discoverable”), but I think that was required by SMB in general, not related to public vs private shares. 

If this changes in the future I'm going to have to scramble a bit setting a password on the now public shares, but I think I'lll wait until I really need to.

During my testing above, the public NAS shares were not an issue.  Ny home network is always set to private.  The only issue came from having a mapped drive (public or authenticated) to the same NAS and then trying to map the drive in Acronis.  If I remove the mapped drives in Windows, then configure Acronis, it works.  I can then re-map the network drives (including the public ones) and everything works like it's supposed to as long as I don't try to mess with the NAS location in Acronis again. 

Bobbo_3C0X1 wrote:

Patrick,

Honestly, I'm not sure.  I just did some more testing.  I can repeat the issue over and over when I have a mapped network drive to the NAS and then try to create a new backup to one of the NAS shares that use the same credentials.  After I drop the mapped networked drive and go back into Acronis, then I can select it as a source using the browse >>> network >>> NAS method and all is well.  Once it's configured and working, as long as I leave the destination alone in Acronis, I can go back into Windows and map the drive again, and everything seems to work fine from that point on.  Perhaps this is the work-a-round for now. 

...

Perhaps this is an Acronis bug since it only seems to be a problem with the mapped drive being active when attempting to select the NAS destination... I'm not sure. If others could test by dropping the mapped drives, setting up their NAS backup, mapping the drives again and then leaving things alone and running the backups manually, does that work for you too?

 

I ran a little test that seemed to confirm for public shares what you determined for private shares.

1. I created a little backup on a mapped public share under ATI 2016,  
2. installed ATI 2017 and ran the backup again,
3. switched the destination to a public share on another NAS drive and ran the backup.  Everything was fine so far.
4. I then tried switching the destination back to the original NAS.  Acronis prompted me for credentials.  It's pretty tough to supply them for a public share.
5. I "disconnected" (unmapped) the share, went back to ATI and successfully switched the destination back to the original share with no trouble.
6. I then remapped the drive and was able to take the backup with no problem.

I don't remember whether I used the mapped drive (under This PC) or the IP address (under Network) for steps 1 & 4 so this may not be the best test, but it was good enough for my purposes.  It demonstrated that there is a problem, and it demonstrated that I could cope with the problem. 

I'm pretty certain there's a bug somewhere.  Having a share mapped shouldn't increase the need for Acronis security measures.  And if there is a security issue I'm missing, circumventing that need by temporarily unmapping the share is a security hole big enough to drive a truck through.   I have no idea whether the bug is in Acronis or Windows, but something is wrong here.

I'm inclined to agree it's a bug when mapped drives are in play at this point as well, but am not 100%. I've submitted feedback and a system report with a pointer to this thread. Later tonight, I plan to test with another backup product to see if the behavior can be replicated or not. I suspect it won't be the same behavior but would like to confirm to be sure.

Just wanted to report that the other product did not have this behavior.  I mapped a private share to the NAS in Windows then created a new backup to the same mapped share with that product and the backup ran fine.  I then tried to do the same in Acronis and it would not authenticate. I removed the mapped drive and then tried in Acronis and it connected just fine.  So, this does look like a bug to me now too.

For now, if you do use mapped drives and need to setup a NAS share in Acronis 2017 v5554 (or change/modify the existing one), it seems like temporarily removing the mapped drive(s) in Windows, then setting the shares/authentication in Acronis and saving, and then re-mapping the drives in Windows will do the trick.  Shouldn't have to do this very often (once, twice perhaps?), but hopefully this gets sorted out with the next release now that it's been identified and possibly confirmed.  Please test and submit feedback with a reference to this thread if you haven't done so already. 

Bobbo_3C0X1 wrote:

For now, if you do use mapped drives and need to setup a NAS share in Acronis 2017 v5554 (or change/modify the existing one), it seems like temporarily removing the mapped drive(s) in Windows, then setting the shares/authentication in Acronis and saving, and then re-mapping the drives in Windows will do the trick.

That's what I've been doing since upgrading ATI to 2017.

Yep on all my machines unmapping the drive fixes the issue...

I'm using a trial version of ATI 2017 and have the same problem. It's confusing because when I use it yesterday, it's all right. I tried a full backup and several incremental test, all ok. But today, when I try to edit a job, it keeps showing a dialog of username and password. I entered the right credential but it still shows up. The shared folder could be accessed in windows explorer.
BTW: I also tried EaseUS and Macrium，no such problem.
OS: Win10

For those posters here using a Microsoft Account to log on to their Win 10 machines,  if you cannot connect to a mapped drive because authentication fails try this:

When entering the username enter (.\username) instead of just (username).  Because Microsoft accounts are Domain accounts the added .\ indicates that the user is an authenticated Domain account.

The problem here is that Microsoft wants users to use Homegroup.  If you use Homegroup instead of a workgroup along with a Micrsoft account logon, Windows requires additional authentication for a Domain user account.  When using a Microsoft Account login, the Homegroup becomes part of the Domain and authentication is not required.  If your network is a workgroup however, the workgroup is a local account, access to that local account needs authentication as an Authorized Domain Account to gain access.

Hi Enchantech,

No dice.

I don't think it matters if it's a local account or Microsoft account, and am pretty sure this is Acronis behavior now with the changes that were made to release 1.

I don't have any issues authenticating to the NAS in Windows Explorer at all with a Windows account logged in - public shares or private ones with authentication - they all work directly in Windows. Also, like some of the others, I can't produce the behavior with some different backup products either.

The issue only occurs in Acronis and only if there is a mapped drive to the NAS in Windows file explorer already. If there are no mapped drives in Windows to the NAS, Acronis connects just fine. If there are mapped drives in Windows to the NAS, Acronis won't take the password. Dropping the mapped drive first, then connecting to the NAS in Acronis allows it to authenticate and then we can go back in and map the drives back in Windows and things will work after that... unless you try to edit the connection settings in Acronis again or setup a new one (while the mapped drives still exist in Windows).

So there is a work-a-round (temporarily unmap the drive letter in Acronis first and then go back and map it after you've created the connection in Acronis), but it's not working as it should at the moment.

The 2nd work-a-round that I've found is if the mapped drives are connected via DNS hostname (i.e. \\WD-MyCloud\ShareName), then I can map the NAS and authenticate in Acronis if I use the IP instead (i.e. \\192.168.1.100\ShareName) - even with the mapped drives in Acronis. For this to work seamlessly though (at least right now with the current behavior of mapped drives causing an issue for Acronis), one would have to make sure that all stored Windows credentials or mapped drives in Windows are using the DNS HostName and then all NAS connections in Acronis are only using the NAS IP address. Won't work if there is a mix of DNS HostName and IP address in either Windows or Acronis.

So then I started thinking, if you're using a mapped drive in Windows, why not just use it in Acronis instead of connecting via the NAS option or network option (why not just use the browse >>> my computer >>> mapped drive letter in Acronis)? That seems like it would bypass the credential process in Acronis since the drive is already mapped in Windows and should appear a a local drive in Acronis (or so I guessed). Unfortunately, no luck there either as Acronis still treats it as a network drive, prompts for credentials and fails to authenticate due to the same behavior if there is a mapped drive in Windows to the NAS already.

Have you been able to test this in your environment too, or is it working for you? Don't even worry about public shares or anything else. Just map one of your existing NAS shares that you use in Acronis currently as a drive letter in Windows. Then go back into Acronis and attempt to change the source of your currently working backup that is configured with the NAS as the destination. Edit the destination, expand network, and click on your NAS... should prompt you for credentials. That windows should already be populated with the credentials you previously entered, and then click on "test" - it will most likely fail now. Then cancel out of Acronis without making any changes, go back to the Windows side and unmap the drive letter in file explorer and go back into Acronis and edit your existing task destination like you did before. It should authenticate just fine now.

I just wonder when will this be fixed? Obviously it's a known issue.

No idea - hopefully whenever Acronis releases the next update. Please submit feedback and reference this thread though if you haven't. The more Acronis sees it from customers, the more likely it will get priority and be updated. It's not often that Acronis has issued stop-gap updates for specific issues - they usually come out in quarterly (every now and then monthly) releases that address more than one issue.

I tried your solution, but still not work.
My logic is simple : if other software, like EaseUS, Macrium, don't have this problem, then surely it's a bug.
I can't give any suggestions on how it happens, because yesterday I did a lot of test, and all OK. Today, my NAS server didn't change any configuration, my PC works well with NAS shares, but such problem occured. If this is a problem of Win10, it should occur when I first do the backup.
Hope Acronis will fix it.

I don't know yet Bobbo, I just ran accross what I posted late last night, did not have time to test myself and could not anyway as I do not use a Microsoft Account to log into Windows 10 but wanted to get it out there so others might try.

If I have time this afternoon I will give the mapped drive thing a try.

Question for posters not having success, are you using DHCP for your connected mapped shares?  If yes does changing to a static IP address for those shares help?