doocoo Tang wrote:

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.

There's no doubt in my mind it is a an Acronis bug - stated up above as well.

However, I've tested this for days on several different systems and VM's now and can successfully produce this NAS connection failure behavior, but can also successfully apply the work-a-round over-and-over-and-over. You may have missed a step or are still trying to edit/create a backup task in Acronis when mapped drives exist in Windows. Right now, it will always fail to authenticate in Acronis as long as any mapped drive to the NAS is connected in Windows. Once you temporarily disable ALL OF THEM, then edit your Acronis task or create a new one and authenticate. Once that's done, leave it a alone and map your drives in Windows again. The backups will run now, but if you try to edit your task with the mapped drive in Windows again, or try to setup a new one while you have mapped drives, you'll not be able to authenticate in Acronis again. You have to drop the mapped drives in Windows first EACH TIME you plan to edit your Acronis backup task or create a new one... until this is resolved in an update by Acronis.

I think this update may be part of the issue but not simply.  I have always used authenticated users.  Someone posted a work around earlier where if shares are disconnected the claim was it would work.  I find this to be accurate.  I disconnected all my mapped drives and now I can authenticate with ATI just as before.  The issue reappears the minute I have the share connected and try to use ATI at the same time. 

This all worked fine before 2017 update.  So call it a security enhancement if you must, but I call it broken, and a pain in the ass.  If they continue to make it so secure I can't use it, I will just go to another backup service. 

In any case, it looks like the issue has to do with multiple connections to the CIFS share from the same host.

Hi Glenn,

I don't think it's a security enhancement - I'm pretty sure it's a bug now. If it was a security feature, then the reverse should create the same behavior. However, I have no issue mapping the drive in Windows while the backup is running in Acronis... I would expect that to fail if it fails the other way around too.

Are you saying that you can't manually kick off a backup while your drive is mapped is Windows after you've set it up in Acronis and successfully connected? I can. I just can't modify the credentials or make a new backup while the drives are mapped. Having a mapped drive is not preventing the backup from running once they have been setup in Acronis, it is only preventing the initial authentication from within the application (another reason I'm pretty sure it's a bug since the behavior only exists at this point and not after the credentials have been authenticated and then the drive is mapped in Windows).

Thanks. Yes. I see the same as you. Except I had on backup that was not to a mapped location and it failed all the time with mapped drives. This is just a fine little bug. Hope they fix it soon.

OK,  I just tested out this mapped drive scenario and here is what I found.

First, I created a mapped drive (Z) to a folder, My Movies, on a WD MyBook 4TB external drive attached to my router via USB 3.0.  Immediately after creation of the drive I opened True Image 2017 version 5554 and created a test backup of my C: drive, selected the newly created mapped folder by clicking on the NAS location which lists my router as a destination location from which I can expand the tree view presented and locate the My Movies folder.  I select that folder and am greeted with a credentials logon box.  Entering credentials and connection test FAILS.  To me this is expected behavior because I am already logged on/in having just created this drive/folder in Windows File Explorer.  So I now click on Cancel which results in the backup task which I just created being removed from the list like I had done nothing at all.

So lets try again, I create the exact same task except this time I select the My movies folder destination by selecting Browse, then Network, then Router, then My Movies folder.  Click on Ok and destination is accepted no problem.  Click on Backup now and backup runs to completion.  After backup completes and without closing the True Image app. I open File Explorer and create yet another new mapped drive to the same physical drive except I now select the folder My Downloads as the new mapped drive (Y).  Minimizing File Explorer I select the just created backup task which just ran successfully to mapped drive (Z) folder My Movies.   I clicked on the Destination icon to change destination to the newly created mapped drive (Y) folder My Downloads.  Next step was to select the new (Y) destination location by clicking on the NAS location icon again and selecting the My Downloads folder.  Result, True Image application crashed. 

Reopening the True Image application brought up the Feedback panel so I filled out feedback on all of the above and included a system report.  After that was finished True Image opened up into the GUI so I went for it again except this time I browsed to the new drive (Y) My Downloads location using the Network path.  Selected the My Downloads folder which succeeded and ran the backup.  This resulted in the successful creation of an incremental backup of the original backup.  This to me is expected as the backup I created is an Incremental scheme backup.  I suppose you could call it a failure if you wanted to as true, the drive/folder destination did change however, it is well known that changing or modifying an existing task in the application often produces unexpected results and I believe this proves that once again.  Moral, once a task is created do not change it, create another task if you need something different.  The good news is that after this excersize I choose to Delete the backups and associated task and that action resulted in both backup files, the one on drive Z and the one on drive Y were deleted and the backup task removed from the list in the GUI.

So is this a bug?  Yes it appears so.  Do you need to jump through all the hoops of unmapping and remapping drives?  It does not appear so to me here.  If you select your mapped folder from the Browse, Network, (Target) method it appears to work.  So for the other posters in this Thread you might wish to try selecting your mapped drive/folders via the Browse, Network, (Target), folder method and see how that works for you! 

Thanks for verifying the behavior as a bug and reporting it too.

No dice for me unless I unmap in Windows first. I've been using nothing but the browse >>> network >>> NAS method the entire time. I had the firewall rule blocks in place for the cable modem issue in the original release and forgot they were there so never had the option to try with the NAS setting. Removed those firewall blocks and tested again in hopes I'd get the same behavior as you, but it still won't authenticate unless I remove the mapped drives.

Just to be sure, when you mapped the drive in Windows, you used the exact same method in Acronis (DNS host name in both locations?) If they are the same, mapped drives kill it. If I map in Windows with hostname, but use IP in Acronis, then it works.

I just found that it doesn't have to be a mapped drive.  If you have the location open in Explorer it will fail auth. too.  As soon as you close Explorer it pops right in.

in my case when using the Browse, Network, Target method the path is Hostnmame\Folder (\\hostname\folder).  If I use the NAS icon methd then the path is nas:\\ROUTER.ASUS.COM\folder.  IP address is not used in either case.  In the application GUI the NAS icon does show below the word NAS the router IP address \\192.168.X.XX\.  So it would appear that the failure in my case in the use of the IP address and not otherwise.  In Windows I used hostname\folder as well, no IP address involved.

I can also get it to work with File Explorer open while creating and running the backup task itself. 

Bobbo,

If you can would you have a look at Control Panel, Devices and printers.  You might have to modify the view but look at how your router and your MyCloud are discovered and post here.  I want to compare as I am thinking my router reports itself twice, once as a router via netbios and on as a media device via SSDP because it has Cloud capabilities.   I had to report to my real job tonight so can't check mine to verify till I get back.  

Since when I select the NAS icon in the GUI the shows as a .COM I am thinking that might be the reason for my failure there.

Enchantech wrote:

Bobbo,

If you can would you have a look at Control Panel, Devices and printers.  You might have to modify the view but look at how your router and your MyCloud are discovered and post here.  I want to compare as I am thinking my router reports itself twice, once as a router via netbios and on as a media device via SSDP because it has Cloud capabilities.   I had to report to my real job tonight so can't check mine to verify till I get back.  

Since when I select the NAS icon in the GUI the shows as a .COM I am thinking that might be the reason for my failure there.

At the moment, my router doesn't show up at all. I have UPnP disabled on the router itself and I removed the attached hard drive and the SMB share on it when I got the WD-MyCloud. The WD-MyCloud shows up at the top under devices (but not under media). Properties of it from this area show that it is using UPnP though and is given a default categories in Windows as:

Network storage device, Entertainment device, Digital media renderer, Network infrastructure device, Storage device

WD-MyCloud model # is: WDBCTL0040HWT

I am currently using firmware v04.04.03-113, but see there is a newer one. I'm not tempted to upgrade since things are working fine with it and am more leery or breaking something with a firmware update. The release notes history are pretty vague on all versions and don't list the samba or SMB versions in use (http://support.wdc.com/download/notes/WD_My_Cloud_Firmware_Release_Note…). The user manual is no better help here: https://wdc.com/content/dam/wdc/website/downloadable_assets/eng/user_ma…

WD-MyCloud:/# smbd -V
Version 4.0.0rc5

K, you can get the discovery method details by adjusting the view.  I changed mine that way so long ago that I can't remember exactly how.   You essentially add a column in the details entitled Discovery.

I am going to check mine again when I return.   I'm also going to try logon as a Domain user because I think that might work in my case.  I never tried to connect to my router attached drive via the NAS icon as I found it just as easy to get there via browse/network. That method works perfectly for me.

There is no column in the Control Panel > Devices and Printers view for Discovery method, but if you open This PC and then click on Network view, you can change the view options there to included this extra column.

Thanks Steve, like I said, it's been awhile!

Hi guys,

I have one for "netbios" and one for "ssdp". Neither shows the protocol or version of that protocol in use though (let's assume SMB though since this is Windows 10 which supports smb 3.1.1).

I was hoping to determine the specific version of SMB/SAMBA implemented on the NAS itself in case that made any difference as even though Windows 10 supports smb 3.1.1, I'm guessing the NAS is using an older version of the smb protocol. Best I could tell, this would need need to be pulled from the NAS itself. The WebGui for the MyCloud is useless and so is the documentation I can find on it from WD and/or forums. I'm not a UNIX person so the best I could come up with using SSH terminal to the NAS was the command:

smbd -V

which reports (in my case): Version 4.0.0rc5

I think this only reports the version of SAMBA being used (which is old - 2013 if that is the case): https://www.samba.org/samba/history/

I'm still unsure specifically which version of SMB this NAS uses to connect with though. NOt sure if it even really makes a difference, but perhaps it might from NAS to NAS in some cases with Windows 10.

Figured it out. Use powershell while navigated to your NAS share and then the following command:

Get-SmbConnection

The WD-MyCloud is using SMB 2.1

Hi Bobbo,
I truly admire the quality of time and efforts you guys put into trying to figure this out, no wonder why many of you are "Acronis MVP Volunteers". Thanks!

By now Acronis should have plenty of information on how to replicate this issue and come up with a patch fix ASAP.

My NAS device, a Seagate Black Armor is a few years old using SMB version 1.5, but despite that, it is a rock solid and reliable device and so far, it has been proof here that this is simply an issue with Acronis.

Thanks for going the extra mile Bobbo! I am going to investigate my system as well and will post results here.

I too am not sure if SMB version has a role here but, I will say that I have read that it is possible that SMB1 is disabled on some systems or that Windows will not successfully default to SMB1 when needed due to the security holes associated with it. Not sure how accurate that is however.

I am curious though why on my network I can and have always been able to authenticate to my attached NAS and network drive without issue using the Browse, Network, Folder path to do so. Using mapped drives in that manner makes no difference either. It also gets me why my router under the NAS GUI icon in the application displays hostname "ASUSROUTER.COM". That would to me indicates a Domain device so as I said before I am going to attempt authentication as a Domain user to test that out. The only reason I can think of why it reports itself this way is because of the discovery method used to do so and the fact that it is in addition to being a router a Cloud media device.

Thanks for the kudos. It just bugs me not knowing so I feel compelled to try and learn more about Windows and Acronis to get to the bottom of the behavior.

I'm curious to see the different behavior with your system and mine. One of these days, we should webex (or something similar) and share our setup and findings. I'm sure we're losing some of the actual behavior in the typing and could suggest some ideas while seeing the others computer. Heck, I wouldn't mind doing this with some of the other MVP's from time to time anyway. Would be kind of cool if Acronis hosted training or Q&A sessions from time to time too.

I'll probably hook up my ASUS AC-1900 router SMB share and do a little extra testing to make sure the behavior I see is not unique to the WD.

I found some stuff in the Knowledge base, thought I would pass it along.

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

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

I just spent half hour on the phone with ATI support. We went through the whole thing and they confirm the authentication issue is a known issue with SMB shares and are working on a fix. The recommended work arounds are as described in this thread. Either disconnect all other connections to named host or use IP address.

Hi Enchantech,
Thanks for sharing those articles, but in this case, and to avoid confusion, those articles do not apply to the issue reported in this thread.
We are not trying to backup to a mapped drive, in fact, ATI 2017 which is the one I am using, will not even list mapped drives as a target path and the reasons explained in those articles made perfect sense to me.

Edhy,

That is correct, I posted these so that it be known that some limitations have/do exist with using mapped drives.

I realize that there are some software applications out there that demand the use of mapped drives however, I believe in the near future those will either change or cease to exists as the threats of malware such as Crytolocker having the ability to wreck havoc on servers with mapped drives become more prolific the IT community will simply ban all use of these scenarios. Users will just have to move on I think.

I reported this as a bug to Acronis. I received the following reply today:

"I have discussed this issue with the expert team and would like to inform you that it is a known issue and our development team already working on it. I am afraid as of now there isn't fix available."

Using ATI 2017 on Win 10 Pro build 1607 (Anniversary edition) have a drive mapped to the public folder of a Thecus NAS (public folder=no credentials) and cannot connect! I have tried using the admin credentials in ATI but they don't work, so currently with a new purchase of ATI 2017 I can't backup to the NAS!!! Not good - I would have thought this was a very basic requirement of any backup application and I note that AOMEI Backupper connects and backs up the NAS on this same system no problems. You have to fix this Acronis

keith crook wrote:

Using ATI 2017 on Win 10 Pro build 1607 (Anniversary edition) have a drive mapped to the public folder of a Thecus NAS (public folder=no credentials) and cannot connect! I have tried using the admin credentials in ATI but they don't work, so currently with a new purchase of ATI 2017 I can't backup to the NAS!!! Not good - I would have thought this was a very basic requirement of any backup application and I note that AOMEI Backupper connects and backs up the NAS on this same system no problems. You have to fix this Acronis

Mentioning this on the users' forum isn't going to get it fixed. You need to, at the very least, provide feedback to Acronis using the link at the top of this page.

Regarding your problem, have you tried the circumvention mentioned in this thread? If it didn't work you may have a different problem ... making it even more important to let Acronis support know about it.

If you are running into the bug discussed in this thread, then, yes, you will be asked for credentials for a public share, and yes, it's really hard to provide them. But if you can briefly unmap the share Acronis will let you define the share as a destination. You can then remap the share.

I am back to report my findings on my system after extensive testing and discovery work. Be advised that my findings may not apply to you or our situation as I am of the opinion that differences in hardware, SMB versions, SAMBA versions, and connections of network devices all have or may have an impact on results per individual user and or PC.

It is first necessary to outline my network system here so that a clear picture can be obtained as to why my results in testing are what they are. So here goes:

Computer: 1 month old custom desktop running Windows 10 Pro X64

Network: 1 Gigabit ethernet. Network devices: Asus RT-AC3200 Multi-band Wireless Router - WD MyBook 4TB USB external drive attached to router - FreeNAS Linux Server

Additional network device: Trendnet Green 8 port Gigabit switch. (All PC's and devices connected to switch, switch connected to router)

Windows 10 uses the latest SMB version 3.1.1, confirmed in use on my system. FreeNAS Linux server is running freenas version 9.10 stable latest release fully updated with SAMBA 4.3.11 in use. Asus router runs ASUSWRT firmware which supports SAMBA version 3.0 and is further customized by Asus to version 3.0.0438.3479. Windows 10 SMB 3.1.1, FreeNAS SAMBA 4.3.11, and ASUSWRT firmware Version 3.0.0438.3479 all support and have security fixes applied to prevent Man in the middle attack. All of these further only allow authenticated user logon including authenticated Guest accounts which are NOT in use. SMB1 version is disabled by default on all of the above devices and is conditional for the man in the middle attack fixes applied. SMB2 is enabled so devices adhering to that standard can be used in this network.

For discovery I went about figuring out the above information which took some digging when it came to the router. After gathering this information and verifying exactly what my hardware is using with regard to versions of SMB and SAMBA I then decided to have a closer look at my routers discovery methods in Windows Network view. If you have been following this thread you might have noted that I asked Bobbo to verify his routers discovery methods which did not work out as he had removed his router from the picture. My reason for wanting to know that is because I had a suspicion that network device discovery might be playing a part in this issue with mapped drive authentication. What I found for my router was that the router is listed 3 times in the network map in Windows 10 network view. It is first listed as a computer with discovery via NetBIOS. It is further listed a second time as a Media device with discovery via SSDP and yet is listed again a third time as a Network Infrastructure device with discovery via SSDP. These 3 entries were key to finding out what the problem was on my system as will be discussed later.

For testing I started with a clean slate creating a mapped drive, letter Z, to an existing folder on my WD MyBook drive attached to the router. I then opened True Image and created a backup task of a secondary internal data drive in my computer and selected the mapped drive folder as destination. Of note here, my router appears twice in True Image. It can be found by Selecting Browse, Network, Device which in this view has the name RT-AC3200-76B0. The router can also be found under the NAS folder icon in the GUI. In that view however the router has the name ROUTER.ASUS.COM. I selected the Browse, Network, Device path for the first test as this method had always worked for me in the past and it did indeed work for me again this time as well. Note: when selecting this path destination I was not prompted for credentials by True Image. The application accepted the destination without my supplying credentials and I am confident that is because the application already has them stored. After that backup I created a new backup task, this time of my OS system disk. When selecting the destination I decided to change to the NAS folder icon method. Selecting that showed a view with destination path as NAS:\\ROUTER.ASUS.COM\. I suspected this was the problem for my system not wanting to authenticate using this method because to me it was the wrong path so what I did was I clicked inside the path box at the top of the screen, removed the ROUTER.ASUS.COM and replaced it with NAS:\\RT-AC3200-76B0\mapped folder name and then clicked on the > carat on the right side of the path box. Immediately what I had typed appeared in the directory tree view below. Encouraged by that I selected Ok which took me to the Backup Now screen, clicked on that and the backup began and ran to completion. Again no prompt for credentials occurred.

Now a few things here. I am confident that had I used the IP address of my router rather than the device hostname I would have achieved the same result. So the solution offered by tech support and of Bobbo of using the IP address in making connection is certainly valid. Further, I would say that my suspicion that network device discovery playing a role in this issue on my system proved correct and here's why. If I open a browser window and type in router.asus.com I am taken to the WEBGUI interface page for the router. This is why my credentials failed to authenticate to that path. That path is being used by True Image I believe because it is picking up this information about the device from the SSDP discovery method rather then the NetBIOS discovery method which identifies the correct path as RT-AC3200-76B0.

I realize that other posters here do not have their NAS attached to a router or switch, actually, they probably do but it is in the form of a cable modem or DSL modem. None the less your device should show up in Windows File Explorer under Network under This PC for users of Windows 10. Make note of the name you see here. When selecting the destination for backups to your mapped drive folder use it instead of what is pre-populated in the path box of the destination screen followed by the share folder name. Or, replace the device hostname with that of the device IP address, either will work. In some cases there may not be a hostname at all just the word NAS:\\ Just fill in IP address or hostname as you wish along with \folder then click the > carat. That should do it.

I do not think you should be prompted for credentials unless this is the first time you have setup a backup to the networked device. If you are prompted for credentials and you have previously setup a backup to this same device then if you are using hostname remove it and use IP address. If you still are prompted for credentials then you have some other issue like the device you are trying to select uses SMB1 for example and your Windows install has SMB1 disabled by default like mine does.

Be advised that even though I had/have success with this the above actions may not stay persistent in the True Image application. They certainly do not on my system which is why I find it easier to go the Browse, Network, Device, folder route. Having said that the use of IP address may make the connection persistent as long as that IP address is static and not assigned via DHCP. So the bug in my case here is the fact that device discovery fails for the NAS icon method due to incorrect device path which is attributable to SSDP device discovery. At least it appears that way to me. I will be passing this along to Acronis support in hopes that it will assist in development of a fix for this issue. It is my hope too that some of you find this helpful in developing a workaround for your system until a fix is released by Acronis.

Enchantech wrote:

...

I realize that other posters here do not have their NAS attached to a router or switch, actually, they probably do but it is the form of a cable modem or DSL modem. None the less your device should show up in Windows File Explorer under Network under This PC for users of Windows 10.

I think that may not be the case.  If the router does not have some typically computer-based function running - a file server of some sort, for instance - it won't necessarily be running anything that responds to netowrk discovery queries from Windows. 

It will almost always have a DHCP server running so Windows will be aware of its name as contained in the DHCP exchange - ROUTER.ASUS.COM  in your (and my) case - but that is all.

My router appears on nowhere in a Windows File Explorer display because it has no network or storage function.  My 2 NAS devices - Ethernet cabled to the router - do appear as discovered by SSDP

Enchantech wrote:

Make note of the name you see here. When selecting the destination for backups to your mapped drive folder use it instead of what is pre-populated in the path box of the destination screen followed by the share folder name. Or, replace the device hostname with that of the device IP address, either will work. In some cases there may not be a hostname at all just the word NAS:\\ Just fill in IP address or hostname as you wish along with \folder then click the > carat. That should do it.

I have never seen the NAS:\\?  Is that for devices appearing under "My NAS connections"?  I never see anything there, and thought that Acronis would list only NDAS devices - NAS devices that use the LPX (Lean Packet Exchange) protocol.  I didn't know that was available on WD NAS devices.

I've probably misunderstood a lot in your posting.

Patrick,

I think you got the jist of my post correctly.  The ASUS RT-3200 Tri-band router does support typical computer based functions as you put it.  Things like Act as a SMB Master Browser, CIFS client support (for mounting remote SMB share on the router), Advanced OpenVPN client and server, Cloud access to attached media, Web storage, FTP server, NFS support, to name a few.  These functions are present due to the ASUSWRT firmware being based on the enthusiast Tomato router firmware which is a Linux core fimware.

What router are you running?  You state the network discovery of your router is vai SSDP, is there a difference in name of the router as seen in Windows Network vs. the True Image destination screen?  If yes, have you tried changing that name in the True Image app to match that with what is displayed in Windows and if yes did that work?

The reference for NAS:\\ is what appears in the path box which you will see once you select the NAS icon on the main destination screen.  That Icon may not show up because as I suspect that discovery is broken.  Try this, before opening Acronis True Image using Windows File Explorer navaigate the the NAS device and logon if necessary.  once you have done that close out the File Explorer session and open True Image.  Create a test backup of say a few files or small folder.  After making that selection choose the Destination icon in the GUI and see what now appears in the list.  You shouldl now see the NAS icon that I speak of.  Select that and at the top of that screen you will see a path box/field where the NAS:\\devicename will be shown.  This is what I am talking about changing to match that of what appears in Windows Network.

If you still do not see the NAS icon on the main destination screen this path box/field is still displayed if you select the Browse icon.  Look at the top of that screen and you will see the words Back up to: and the box/field I speak of.  Enter your devicename\sharefoldername in this format: \\nasname\sharefoldername\ Then click on the > carat to the right side of the box/field and if the path is correct your device will appear in directory tree view below.  You can at that point navigate to the folder you need.

I will point here that when you locate your mapped drive folder you will not see any drive letter as the application will not display it.  Only the folder will be shown but selecting that folder will result in the app creating the backup in the mapped drive in Windows File Explorer view.

Enchantech wrote:

What router are you running?  You state the network discovery of your router is vai SSDP, is there a difference in name of the router as seen in Windows Network vs. the True Image destination screen?  If yes, have you tried changing that name in the True Image app to match that with what is displayed in Windows and if yes did that work?

I have an Asus RT-N56U.  If I said the router was discovered via SSDP, I misspoke.  My NAS devices are discovered by SSDP.  My router isn't discovered at all ... at least not so that it shows in File Explorer.  Windows know of the router only as a router ("gateway") and as my LAN's DHCP server.  (It used to show as such in the old Win7 fulle network display, but that display doesn't exist in Win10.)  In other words, as far as Windows is concerned, my router is just an IP addr with an associated local DNS name.

Enchantech wrote:

The reference for NAS:\\ is what appears in the path box which you will see once you select the NAS icon on the main destination screen.  That Icon may not show up because as I suspect that discovery is broken. 

From what I've read (which may be obsolete), I have nothing in the NAS display because it displays (or used to display) NAS devices only if they are NDAS (Network Direct Attached Storage) devices using the LPX protocol.  At least that's what I've read in the Acronis KB.  If that is no longer the case I must have something set up wrong somewhere.  I've got a MyBookLive and MyCloud cabled to my router and neither show in the Acronis NAS display.  I have remote access and media serving disabled on both devices.  Maybe that's part of the "problem".

Enchantech wrote:

Try this, before opening Acronis True Image using Windows File Explorer navaigate the the NAS device and logon if necessary.  once you have done that close out the File Explorer session and open True Image.  Create a test backup of say a few files or small folder.  After making that selection choose the Destination icon in the GUI and see what now appears in the list.  You shouldl now see the NAS icon that I speak of.  Select that and at the top of that screen you will see a path box/field where the NAS:\\devicename will be shown.  This is what I am talking about changing to match that of what appears in Windows Network.

If you still do not see the NAS icon on the main destination screen this path box/field is still displayed if you select the Browse icon.  Look at the top of that screen and you will see the words Back up to: and the box/field I speak of.  Enter your devicename\sharefoldername in this format: \\nasname\sharefoldername\ Then click on the > carat to the right side of the box/field and if the path is correct your device will appear in directory tree view below.  You can at that point navigate to the folder you need.

I will point here that when you locate your mapped drive folder you will not see any drive letter as the application will not display it.  Only the folder will be shown but selecting that folder will result in the app creating the backup in the mapped drive in Windows File Explorer view.

I'll try that, but probably not today.  I don't really have a problem (other than the topic of this thread, and that problem is easily circumvented).  I don't actually need my NAs devices showing in the ATI list of NAS destinations.  I've got everything working without it.  I'm just curious how other people get that display and I don't.  I'm especially interested if they don't have NDAS devices.

Why not just fix the issue? I have one 2016 works fine and one running 2017 that does not. Guess Im not upgrading the second one. lol

Ok,  The NAS display probably does show nothing in your view in ATI given what you say here.  I do think that your router supports and is run using the ASUSWRT firmware so it would be a linux based core firmware. Having remote access disabled on your NAS devices may be your problem. You could enable it temporarily to test.

The NAS icon or path, if in Browse view as shown in the directory tree, will now display current day NAS devices, as long as discovery works correctly which I believe it is not curently.  By entering the path to the device manually you are basically forcing the app to discover the device.  Once you do that persistence in it appearing are much greater.  In fact I just fired up TI on my system from being completely shutdown and now the GUI displays the NAS icon on the destination GUI screen.  When selected however it shows the name of device/path incorrectly as before.  I have not tried the IP address yet but that might make this aspect of the devices persistence work where as mine using hostname may not.

I think that if you happen to have one of the old LPX NDAS devices it would still show up in the directory view under NAS.  The enhacement here for 2017 was to add curent NAS device support to that area of the application but because of the discovery issue is not working as intended.

robert,

It's being worked on.  The goal here is to find temporary workarounds for user to apply in the interim.

Enchantech wrote:

Ok,  The NAS display probably does show nothing in your view in ATI given what you say here.  I do think that your router supports and is run using the ASUSWRT firmware so it would be a linux based core firmware. Having remote access disabled on your NAS devices may be your problem. You could enable it temporarily to test.

Yes, the router is using ASUSWRT firmware.  As far as I can determine, the WD remote access function in the NAS devices just connects the devices to the WD remote access server.  I don't think it does anything that changes the visibility of the devices on the LAN, but I will try enabling it some time this evening. 

Update:

I didn't wait until evening. 

Before testing Window's File Explorer showed my MyBookLive and MyCloud devices under Computer (discovered by NetBIOS) and Storage (discovered by SSDP).   Acronis showed nothing under NAS.  Actually, nothing in the following test changed Acronis behavior.

I activated Remote Access on MyBookLive and Cloud Access (whiich I think is the same thing) on MyCloud.  Nothing changed on Windows in general or in Acronis in particular.  I then enabled Media Streaming on both devices.  Still no change in Acronis, but the two NAS devices showed up in the File Explorer display as Media devices (discovered by SSDP).

I then activated router support for UPnP which I normally have disabled.  (In my router the UPnP option is under the WAN settings.  UPnP was intended only for local use and is considered a security risk by some when exposed to the internet.  So I keep it disabled.)  My router then appeared as a Network Infrastructure device (discovered by SSDP) in the File Explorer display.  Given that change, I reran all the previous parts of the test, but there was no change.

I think my devices are just not going to show up in ATI as a NAS destination.

I really don't have time to fault find Acronis' problem.  In my case I have unmapped the drive to the NAS and remapped it - same result - asking for credentials and then not accepting them (even though the drive is mapped to a public folder that doesn't need an credentials).  If I try to specify the ip address instead ATI 2017 crashes (stops working).  As stated previously I can instantly get accees to the NAS (a Thecus N2200Plus) via the mapped drive or the ip address.

I have downloaded the 2016 versio of ATI (posters have said that this version does not have these issues).  Does anyone know whether the product key for ATI 2017 will work for ATI 2016?

Thanks for everyone that has attempted to work around this issue

Hi Keith,

What worked for me, temporarily is to do the following before open ATI:

1. Stop the service name "Workstation", this will stop some related services including SMB Redirector and will disconnect any connection to any NAS or mapped drives.
2. Open ATI and do what you need to do, credentials should work at this point.
3. Once done with ATI, just re-start the "Workstation" service.  if you had mapped drives, simply open Windows Explorer and click any mapped drive to reconnect.

Hope this help you until a permanent fix is available.

Yes, we're all waiting for this to be fixed - it needs to be resolved and I'm sure it will be in the next release.  This did work in the first release of 2017 and in 2016 so I'm sure Acronis will correct this in the next update.  Until then, here are 3 work-a-rounds for the meantime- all verified to allow a new NAS authentiation in Acronis until Acronis fixes this issue (public shares may still be a problem as Acronis seems to want you to enter credentials, even on a public share.  

1) stop workstation service and restart it.  Then create or modify Acronis NAS credential authentication in your backup task

2) in Acronis, use the IP address of the NAS instead of the DNS name (or, whatever you're not using for your mapped drive already

3) unmap all mapped network drives in Windows first, then modify your backup task or create a new one to your NAS

~~~~~~~~~~~~~~~~~~~~~~~~

Enchantech, 

I hooked up my ASUS AS1900.  Like you, I did not see this behavior initially - it just worked, even with a mapped drive.  Amazingly, after I mapped the SMB share to this second NAS device, I didn't have issues with this share or the WD-Mycloud in that Windows session either.  However, I experieneced this once before and decided to reboot to see if it would continue to work or not.  As expected, after the reboot, Acronis asks for credentials on both the WD-MyCloud and the ASUS AC1900 again - perhaps it's related to how the WD is connected, I don't think so though.  Maybe see if your luck holds up after a reboot too with your mapped drive.  

Also, the ASUS AC1900 is using SMB 1.5, the MyCloud is using SMB 2.1 and my Win10 PC is using SMB 3.1.  Dont' think it really matters - just seems to be a bug at this point, but at least we have some work-a-rounds until it's fixed in the next release. 

KB article has been posted acknowledging the issue with some additional recommednations:

59051: Acronis True Image 2017: Connection to NAS fails with errors "Connection failed", "Failed to check credentials", "Can not find files and folders".

I'm glag Acronis is working on this problem, and I'm glad they are providing a description of the problem and circumventions, but I think they are being a bit disingenuous to blame the problem on the stated Windows restriction.  That restriction is a major pain with no obvious benefit, but it has been around for years.  It didn't just pop up.

I'm not sure that the Method #2  mentioned in the Acronis KB article 59051 actually works in all cases.  It DOES circumvent the Windows restriction and allows multiple connections (with multiple credentials) to a SAMBA server, and I was able to have ATI backup to a private share when I already had a mapped connection to a public share on the same server - something that the Windows restriction normally prevents.  But when I tried changing the destination of that backup to the public share Acronis prompted for credentials (which don't exist for a public share). 

Absolutely correct Patrick.  If, as someone else stated earlier, this issue existed when ATI 2016 was first released it seems Acronis went ahead and released the 2017 version with incomplete testing ie it wasn't ready for release.  As I stated earlier, backing up to NAS is such a common practise these days it's hard to understand that Acronis didn't thoroughly test this aspect before release..  Very frustrating and very slack of Acronis.

Bobbo,

So you put your router back in the mix and initially had success or at least better success than previous attempts, is that correct?

As for your router using SMB 1.5, mine also reports this using Get-SmbConnection however, if you have Firmware revision 3.0.0.4.380.3264 the security vulnerability is addressed.  There is also a more recent update on the ASUS Support page and the update mentioned here does have a disclaimer attached.

http://www.asus.com/US/Networking/RT-AC1900/HelpDesk_Download/

I did reboot my PC several times and behavior remained the same, It is possible to navigate to the share(s), select with no credentials prompt, and run a backup task.

I am of the opinion here that attempts to use a unauthenticated guest account on an NAS device is the real problem here.  During developrmrnt of Windows 10 with the release of Preview build 9926 users began experiencing issues connecting to these unauthenticated accounts.  This was/is the result of a decision made by Microsoft to no longer allow such unauthorized account access on NAS and remote connections.  An excerpt from a statemnet about this from Microsoft appears below:

The security change is intended to address a weakness when using guest access. While the server may be fine not distinguishing among clients for files (and, you can imagine in the home scenario that it doesn’t matter to you which of your family members is looking at the shared folder of pictures from your last vacation), this can actually put you at risk elsewhere. Without an account and password, the client doesn’t end up with a secure connection to the server. A malicious server can put itself in the middle (also known as the Man-In-The-Middle attack), and trick the client into sending files or accepting malicious data. This is not necessarily a big concern in your home, but can be an issue when you take your laptop to your local coffee shop and someone there is lurking, ready to compromise your automatic connections to a server that you can’t verify. Or when your child goes back to the dorm at the university. The change we made removes the ability to connect to NAS devices with guest access, but the error message which is shown in build 9926 does not clearly explain what happened. We are working on a better experience for the final product which will help people who are in this situation.

Microsoft recommended that the following action be taken by users while they worked on a better experience for users:

Microsoft recommended to add an explicit user account and password on your NAS device or remote server which hosts the shared folders or remote file access, and use that account for the connections. Or you can use HomeGroup if everything is running Windows 7 or newer. As Windows 10 can remember the user name and password credentials, so it’s a one-time inconvenience to help secure your data and connections.

I am also of the opinion that the better experience for users here is available but users must fully update/upgrade their devices to achieve that better experience.  In some cases users of older hardware which lack support for update/upgrade to resolve these issues may be well, just out of luck and be forced to replace such hardware with that which is compliant with the security policy of Windows 10.

I do think there are shortcomings with mapped drives here but I am of the opinion that those issues are Windows centric.  I do think that discovery is still at issue in True Image and fixing that would help resolve some of the rest.  Given that Microsoft has pulled the plug on guest user accounts I also think that users need to stop using and/or attempting to use such accounts on NAS devices, establish authenticated accounts, and move on.

Patrick O'Keefe wrote:

I'm not sure that the Method #2  mentioned in the Acronis KB article 59051 actually works in all cases.  It DOES circumvent the Windows restriction and allows multiple connections (with multiple credentials) to a SAMBA server, and I was able to have ATI backup to a private share when I already had a mapped connection to a public share on the same server - something that the Windows restriction normally prevents.  But when I tried changing the destination of that backup to the public share Acronis prompted for credentials (which don't exist for a public share).

I submitted feedback about this circumvention not working.   Support contacted me, first saying that they could not reproduce the failure; then saying they had reproduced it. 

The circumvention does work if I switch the destination to the public share using the new alias name I created.  In other words, let the Windows mapped drive definition uses the device's actual DNS name.  Acronis can use the etc\host DNS alias and can switch between a private and public share using that alias.  I assume a separate alias would have to be created for every unique set of network credentials needed by Acronis, but amybe any of them could be used to access a public share.  (I don't know for sure and I'm not going to test it right now.)

Patrick,

Good job, the so called Alias created by editing the host file does work yes.  In effect creating a shared absolute path to a network location.  Windows using this method can thus authenticate the share as a defined network location.  As long as IP address is static this approach will work.  The result of this approach is that of an authenticated share not an open unathenticated one.

Enchantech wrote:

... the so called Alias created by editing the host file does work yes.  In effect creating a shared absolute path to a network location.

The obvious problem with this technique is that the NAS has to have a static IP address, or that you have to be willing (and able) to re-edit the host file every time DHCP gives the NAS a new address. 

A much better solution would be to add real alias records in the router's name server or in Window's resolver.  I don't think we have any access to Window's resolver (that I've seen), and I don't think many routers give access to their internal DNS server.  Another alternative would be to run a caching/forwarding name server on Windows, but I don't know if anybody makes those.

So you put your router back in the mix and initially had success or at least better success than previous attempts, is that correct?

Yeah, initially, but only for that session.   I had luck with this one other time too when I added a public mapped drive, but also only until I rebooted.  After that, like now, the same issue occurs. 

Unfortunately, my AC1900 is a T-mobile branded model and won't let me flash the standard Asus firmware to it so I'm stuck with it.  It's a decent enough router that T-mobile gave to me for free so I haven't fiddled with trying to force the ASUS firmware on it.  I got my hands on a Linksys EA9200 AC3200 that I was planning to replace the AC1900 with, but have not been happy with the performance of the EA9200 so went back to the ASUS since it's been rock solid.  

Oh well.  I'm not too worried about this issue anymore as I can get the work-a-rounds in place easy enough and suspect the issue will be resolved in the next update anyway (hopefully).  

Guys just for reference, I am having a similar problem. ATIH 2017 b5554, source Windows 10 14393.322, target Windows 10 14393.322 SMB protocol is 3.1.1

Access on Windows via network drive is ok. backup via ATIH is ok. Editing backup job that does work causes authentication failed. I am pretty sure this is a ATIH bug. Cannot tell if it was introed with since b5554 I never touched the job after upgrading from 2016 to 2017 beta.

https://forum.acronis.com/de/node/126927#comment-395761

I kindly refuse to gamble with registry modification @Bobbo just to get it back to work. The way of how the issue presents itself reads much like a code error.

I will provide some SMB protocol sniffing later on.

It could be also originated due to a MS code change as described here: https://support.microsoft.com/en-us/kb/3178465

Hi Karl,

Just follow the instructions in this thread and you should be able to edit your jobs:

https://forum.acronis.com/forum/126528?page=2#comment-395542

Enchantech wrote:

Patrick,

Good job, the so called Alias created by editing the host file does work yes.  In effect creating a shared absolute path to a network location.  Windows using this method can thus authenticate the share as a defined network location.  As long as IP address is static this approach will work.  The result of this approach is that of an authenticated share not an open unathenticated one.

Ok.  I'm finally back to "normal".  (Or as "normal" as I ever get.)  The following description is likely to be boring unless you want to see another twist to the interesting bug described in this thread.  It doesn't provide any additional diagnostic information or circumvention tips. 

My problem was slightly different from the one described in this thread.  The files and folders I was backing up reside on the mapped NAS public share; the destination was on an external USB-connected drive.  This daily backup started failing as soon as I started testing the problem mentioned in this thread.  I now think I understand what happened, and I have finally been able to get back to my original configuration without using the alias.  

In my original configuration Acronis had set no credential records in the Windows registry.  It didn't need any to get to the public share on a mapped drive.  But Windows still had to use SMB to get to that drive, and I was still subject to the Windows restriction of only one SMB connection between a user and an SMB server.  Once I started testing backups to a private share on that server I had (or tried to have) two SMB connection to that NAS device.  (At least I think that's why may backups started failing - why ATI couldn't find the source files.)

I could not change the backup source without running into the bug discussed in this thread.  I could not simply unmap the share because my backup used the mapped drive - the source was from the ATI "This PC" list rather than the "Network" list.  My temporary solution was to give up backing using the mapped definition.   I could get to the folders via the "Network" list, and Acrons let me access it without prompting for credentials if I used the alias.  But that was not the configuration I wanted, and the configuration I wanted had worked for one day after installing ATI 2017 - the Acronis bug did not directly cause my problem.

Luckily, the solution was trivial.  I deleted my test backup definitions from ATI and deleted all of the Acronis SMB connection records from the registry.  After rebooting (which may not have been needed) I was able to once again tell AHI that the source files and folders were on the mapped Z drive under "This PC", and ATI did not prompt me for the (non-existant) credentials.

I admit that I have become pretty casual about registry modifications during the course of these tests and need to reset my head.  Deleting stuff from the registry is not to be taken lightly unless you have a good backup handy and time to do a system restore.

By the way, I am not surprised that the Acronis development team missed testing some of the effects of the Windows SMB restriction, and I will be surprised if this is the last time we see this kind of bug.

Karl,

I agree with you that this issue looks to be a code issue.  I also agree that recent security updates play at least a part in the issue.  I also think that some fault lies in the discovery methods used to detect certain device hardware. 

I am not sure what True Inage uses for password reset but I would bet on NTLM. 

I am most interested to see what your SMB protocol sniffing turns up!

My Operating System: Windows 10 prof x64; Anniversary Update.
WD NAS; Name: NAS1

I had the same problem since installing ATI 2017 (or Windows 10 Anniversary? Did not use
the questionable functions since then).

I spent many hours trying to solve the problem, also with some solutions found in this forum: No success. My situation was as follows:

Path in Explorer \\NAS1\Public\ ......(following Files and Folders) (Public: share)

In ATI, I tried to create a new Backup of NAS1. So:

 +Add Backup (left side, lower corner)  -> Window with two fields: From entire Pc to Cloud. Move mouse curser inside left field. Changes to: Change source. Now klick. I get four huge buttons, the lowest one reads: NAS1. Klick this button. Now you get this mysterious Window where the problem starts.
Authentication Settings; Path \\NAS1; User name: (my username already filled in); Password: with a lot of dots; Test connection; Cancel; Connect.
First: Trying all the Passwords I had, as: Windows Account, E-Mail Account, Router Password. Clicking all the buttons. Always the same result: Connection failed.
Just before getting mad, my brain started to work very hard: Question: Why should you enter a password if you never need one in windows explorer to access NAS1?? So, last trial: In this stupid window, I just clicked the CLOSE BUTTEN. And oops, there I was, with the whole tree of files and folders of NAS1. That is valid also when I want to change an existing backup from NAS1. Difference to Explorer: The path reads: My NAS Connections -> NAS1.HOME -> PUBLIC.

Besides: Windows shows me that I never have defined some credentials. I think it is not possible to define credentials for a single NAS Drive in a local network only for such with different Names. Or you can share Drives of a PC with Drives on another Computer in the network. Or in storage places somewhere in the Web.

Remark: I am using ATI for about 6 years now. The problem appeared recently treating to change the options of a backup of NAS1 Files. Another old one functions  still flawless.

And at last: I am not a specialist. If I should err somewhere, please tell me.

Hello Everyone,

We have been investigating the issue and made fixed versions of TrueImage.exe and ti_managers.dll available for download at https://kb.acronis.com/content/59051. The fix will also be included in the next update for Acronis True Image 2017.

Regards,

Slava