I am having the same problem after updating from ATI 2016 to ATI 2017. Today I upgraded to the latest build of ATI 2017 and am still having the same

problem. Any solution to this Acronis?

I'm not a very good guesser.  More info might help narrow down the problem though.

What type of NAS?  Are you using an open share or using a username and password?  Did you connect using the new NAS connection... did you try using teh browse >>> network  or the browse >>>> (enter full unc path using IP address such as \\192.16831.100\fullpath)  and auhenticating the user as:

nasname/username   +  password         instead of      username + password?

I'm able to successfully connedt to my WD-MyCloud, an Asus AC-1900 SMB share and a Linksys ea9200 SMB share through Acronis.

Keep in mind that Windows is limited in only being able to access a remote network share with one account during a Windows session.  So, if you have multiple NAS accounts, this would be a problem if attempting to connect to them at the same time from one Windows logon session. 

I have a 4TB WD MyCloud NAS and 2 external hard drives connected to an ASUS RT-AC68U router. I have a username and password on both the WD MyCloud and ASUS. I tried to connect using the new NAS connection. I also tried connecting using network and browse.

I tried using nasname/username but it still doesn't work. 

All,

You must reset all previous network sessions in order to have success connecting.  If you are using Windows 10 and have hibernation and fast startup enabled which is the default then rebooting your machine will end all network sessions.  If you are using prior versions of Windows a complete shutdown and restart of your PC is required.

In addition, if you still cannot connect then you should clear the True Image credentials cache which is held in the Windows Registry.  Visit the following link for details on True Image credetial handling:

https://kb.acronis.com/content/58004#Where_Acronis_True_Image_2016_stor…

The Quick solution details the steps necesary to clear the credentials cache.

The following link can help with NAS discovery issues:

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

After clearing the credentials cache, reboot or restart is advisable so as to not have net session conflict.

Whatever I try, is does not accept my credentials to login to my NAS. Existing backup works but can not be changed due to this problem. I also can not create a new backup because of this credential problem. I think it's a bug. V5534 was ok iirc.

Rob,

Contact the Support team and see if they can help.  If clearing the credentials cache and resetting all network sessions does not due the trick then you have other issues that they possibly can help with.

Wanna bet it's a bug introduced in version V5554? :P

I'd take that bet - I'm still connecting to my NAS devices and I have a WD 4TB MyCloud and an ASUS AC1900 which is a T-mobile rebrand of your router and both are working with all versions of Acronis 2017 (including the beta).

Are you using any other backup software like Macrium or AOMEI or something that might keep a stored net use session in the background with credentials to the NAS that differ from what you're entering now?  If so,  this would be cause for the Windows limitation of only allowing one NAS connection per Windows user session (if using different NAS credentials to authenticate to the same NAS device in that single Windows user sessin).  You can run "net use" from command prompt to see if any existing network shares are connected.

If you want to really test...

Create a new temporary admin user account in Windows and log into the PC with it.  Don't connect to the NAS via any means from within Windows.  Check "net use" to be sure nothing is connected.

Reboot the WD-MyCloud - won't hurt and may kill some old/stale connection from your other regular Windows account logon.

When the MyCloud is back online, launch Acronis and setup a NEW backup for the test.  When connecting to the WD-MyCloud, use the "browse" option and then type in the unc path of the share using IP (\\192.168.1.100\nasshare). When prompted for credentials, try just the NAS username and password first.  If it doesn't connect, then try nasname\username (using all caps for the nasname as it shows up under Windows >>> network.  

Any luck with the new account?

Tried a new admin account on my PC, no luck. Rebooted my QNAP, no luck.

i don't feel safe atm... :(

Fix:

Open the registry (regedit.exe), and go to:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

Delete all of the keys, except for the physical drives starting at C:  So you want to leave C, CPC, D, E, F, G, etc...  The rest, including the CLSID/hash values can all go.

Reboot your system afterwards.

Done.

Damned....lost a bet. :(

Hey, you got it working and that's what counts!  And I learned something new in the process too (bookmarked in my favorites for reference)!  I imagine this may be useful to others as well.  

So in a nutshell, in your case, you had a an old/stale/disconnected mapped drive to the NAS that seems to be the root cause of the connection issue instead of bad credentials?  

https://windowsserveressentials.com/2011/08/05/quick-fix-removing-a-dis…

https://support.microsoft.com/en-us/kb/932463

Nope,  as I recall this issue showed up after installing the latest update.  Was working perfectly fine,  just wanted to change my schedule. Then it asked for the credentials it refused to accept. These have been working perfectly fine since Acronis TI 2014.

All I see are CPC and hash values

TurnTrout, I've not seen anyone else need to use the suggestion by Rob (to date).  What exactly is your situatoin. We're you connecting to your NAS with the same backup task/script previously, but now also not working in 2017 or is this the first time trying to connect to the NAS through Acronis, or have you changed logons to the NAS or created any new ones?  Different possible scenarios with different possible solutions. 

Ok, it's a bug. Backup to nas finished, just tried to change the backup scheme and when I fill in the credentials it gives me the same "connection failed" error.

The way to fix it is to disconnect the share all shares in Windows, delete the mount point from the registry, as admin run: net use * /delete followed by a reboot. And then the credentials are accepted again...

edit, connected the shares in windows again, tried to edit my bacxkup scheme, error!

Bug! :P

hmm, is it s rights issue? only when I disconnect all shares in windows I can change my settings.

I got the same (initially), but my backups have been running fine so I know the credentials work. I closed the app and went back in and tried again with the same credentials and then it worked. NOt sure why just closing the app and re-opening it after trying once already then allowed it to work.

Make sure you use the same credentials when you connect to SMB shares as when you set up the backup in ATI. If you first open the share as public, you are using one set of credential (public user), then ATI won't be able to access the NAS with another set of credentials, for example.

You might have some other software accessing the NAS with some other credentials as well.

Just make sure that any software, including Windows explorer, is using the same set of credentials for any share of the NAS for the same windows user session.

Same issue, after updating to 2017... but with changing location for mobile backups... normal backup will allow destination to the NAS ( mounted to the PC as a disk ) but changing location to it in setting for mobile backup it can't authentificate....

Hey Vlado,

I had the same issue when changing the location of a backup. It might be a bug. I can set up my NAS as a destination for a new backup task, but I cannot move a backup to another share on that NAS. I ended up manually moving the TIB files to the new share and add them as existing for a new backup task.

Unmapping my drive letter mapped to a share on NAS solved my problem. Thanks for info.

I'm also having this problem using a Synology Diskstation 213j. Have been running ok in the past with several previous versions of True Image across several PCs. Rebuilt my main PC, installed 2017 and it worked fine for one backup. Then tried on a second PC and it failed. Now it fails on the first PC as well - it can't validate the backup, or make new ones.

Edit - Removing all the mapped drives and MountPoints seems to have worked. ATI can connect again. Going to let the backups complete and then try reconnecting the shares again.

Edit 2 - On rebooting the PC, ATI couldn't connect to the NAS. I didn't reconnect any of the mapped drives - I just rebooted the PC. This is on build 5554

David,

In addition to unmapping the drives, you should delete any NAS credentials from Windows Credentials....then reboot.

ATI stores NAS login credentials in 2 locations...in the registry at:

HKEY_CURRENT_USER\SOFTWARE\Acronis\Connections\smb

And in the script file for each backup task.

If you are comfortable working in the Windows Registry, you can delete the subkeys to the registry key above...then see if ATI will connect to the NAS.  The credentials in the script files should be OK.

Let us know if this works.

Personally, I don't map NAS drives as this exposes them to malware attacks...especially Cryptowall.  ATI does not need the drives to be mapped.

Hi,

i looked together with my daughter at this problem and found out with wireshark that ATI 2017 send independent of the PSW you enter always 0x00 ! This is a fundamental bug that has to be solved immediately.

It cost me a lot of time and my time has a value in itself! Why does acronis release it?

Wastl

And what effect does passing a null character have on a password?  Nul (0x00) has no value so passing this sends nothing.

The result and answer is access denied, the access-control-bits are all zero, no access.

ATI needs mandatory user name and password to verify access

previously I had tried all these tips.

Myself and others do not have issue with autenticating credentials over a network to an NAS.  If your assertion that a sending a nul character was blocking passwords and resulting in access denied errors then eceryone would be experiencing the problem   Since that is not the case there must be something else in your case that is causing this issue.

Cannot connect to my nas either. It worked with 2016 version.

I uninstalled ATI 2017 and installed ATI 2015 and it works!
Thus it can not be due to a different product, except ATI 2017.

System: WIN 10, Avira, Buffalo LS-QVL (NAS), NETGEAR GS724T (Switch)

I'm having the same problem on a new update from ATI 2016 to ATI 2017. This is on a Windows 10 machine. The NAS is an external drive connected via USB to a TP LINK router.

If I remove\disconnect the drive mapping in Windows then ATI 2017 will connect to the NAS. As soon as I map the NAS to a drive letter then ATI fails to authenticate. I've even set the NAS to no authentication required and ATI will will not connect if the drive is mapped to a letter. I can toggle the ATI connection problem simply by mapping and unmapping the NAS.

Unmapping the NAS breaks other programs I use so drive mapping is important.

EDIT:

I've gone through all the tips presented in #31 of this thread and the problem, for me at least, is not resolved.

I did open a ticket earlier today with Acronis support and included the system info file. I don't expect to hear back from them right away but when I do, and if I get a fix, I'll be sure to post it here.

EDIT (adding Windows build info):

Window 10 Home, Version 1607, Build 14393.222

Hello all, with a few of you reporting this behavior, it could very well be a bug.  Have all of those with issues, submitted feedback and provided a system report to Acronis as well?  If not, please do so and reference this thread in your post too. 

However, there could be more to it as well, since this behavior does not appear to be effecting everyone.

For those with the issue in 2017:  

1) If using Win 7 or newer, what is the value of your registry key as outlined in MS16-075 and MS16-076: Description of the security update for Windows Netlogon and SMB Server: June 14, 2016.  If the value is set to 1, does setting it to 0 alleviate the problem (change, reboot, and make sure it is still set to 0 before attempting to connect again).

2) Is everyone who is having problems have a share mapped as a driver letter in additition to attempting to connect via SMB UNC path?

3) For those that answer yes to #2, are you 100% positive that the mapped share and the SMB credentials are exactly the same (same unc path, using either the name or IP and exactly the same username and password)?  Please keep in mind that Windows limits the logged on Windows user to only being able to authenticate to the same SMB device, using the same credentials - you cannot use one set of credentials for say your mapped drive and another set of credentials say for an application such as Acronis to the same NAS device (even if the shares are different).

https://social.technet.microsoft.com/Forums/office/en-US/f3ee2c61-a5c7-48b3-a3bf-23ea323da699/connecting-to-multiple-shares-on-a-single-server-with-multiple-credentials-system-error-1219-?forum=itprovistanetworking

4) If 1-3 are 100% confirmed, what happens if you simply stop and restart the "workstation service" in computer management >>> services and attempt to connect with Acronis right after that?

Steven,

There is a work-around for your situation.  You could create a new user account for running ATI 2017.  In that account, you would not map any drives.  You could then set up all of your backup tasks.

Yes, this is a work-around...but it would enable you to backup to your NAS while this is being investigaged by Acronis.

1. I don't have a SmbServerNameHardeningLevel registry key

2. Yes I have a drive letter mapped to the NAS drive. I need to have this.

3. I am positive that the credentials are the same

4. Bouncing the 'Workstation' service clears to problem. But when I reboot it comes back.

I have submitted feedback.

I am now rolling  back to 2016. I need to make sure my PCs are backed up.

I don't have a system to test on, but for those with this behavior, since it appears that stopping and starting the workstation service temporarily fixes the issue, I would be curious if changing the following value would work as well.  By default, the value appearst to be set to 1, but if changed to 0, curious if it would work or not.  If the NAS connection did change in 2017, presenting the null response may be the issue if this registry change is a work-a-round. 

https://technet.microsoft.com/en-us/library/cc957461.aspx

RestrictNullSessAccess

HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

Description

Determines whether the Server service restricts access to clients logged on to the system account without username and password authentication.

 Note

The name of this entry was documented incorrectly as RestrictNullSessionAccess in the Windows NT Resource Kit 4.0. The name shown here,RestrictNullSessAccess, is correct.

Windows 2000 does not add this entry to the registry. You can add it by editing the registry or by using a program that edits the registry.

The other method (for testing purposes) described in the previous post #31, would be to disable extended protection for authentication of SMB to see if that works either.  Neither of these should be required, but could point to the cause of the issue on some computers. I just wish I could duplicate the behavaior so that I could test myself. 

Disable Extended Protection for Authentication in SMB

Note Before you set any hardening modes, refer to the following MSDN article: Extended Protection for Authentication Overview

1. Click Start, click Run, type Regedit in the Open box, and then click OK.
2. Navigate to the following registry location:
   

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
   

3. On the Edit menu, select New, and then click DWORD Value.
4. Type "SmbServerNameHardeningLevel", and then press Enter.
5. On the Edit menu, click Modify.
6. Set the value of SmbServerNameHardeningLevel to 0, and then click OK.
7. Close Registry Editor and restart the system.

    

Impact of workaround. SMB may not work properly.

How to undo the workaround. 

1. Click Start, click Run, type Regedit in the Open box, and then click OK.
2. Navigate to the following registry location:
   

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
   

3. Select "SmbServerNameHardeningLevel", and then press Enter.
4. On the Edit menu, click Delete, and then click Yes.
5. Close Registry Editor and restart the system.

I just tried the RestrictNullSessAccess registry change detailed in post #34 and it didn't resolve the problem for me.

I will note that my backups are still running, I just can't add new backups or change options due to the authentication failure.

Steven,

Your backups should continue to run...the login information for the backups is stored in the script file for each backup.  

Thanks for trying.   My only other guess since bouncing the workstation service seems to work (for that windows session or untiol reboot) would be to see if setting the workstation service to autostart delay would make any difference or not and rebooting before trying again.

Also, if bouncing the workstation service does allow a new NAS connection to then be made in Acronis... would /does that new connection continue to work after the system has been rebooted as well (without trying to connect/modify to the share again - just manually kick off the new backup job that was created before the system was rebooted).  

All, just to mention that I have the same issue as well. I have two different NAS systems (a large 20TB FreeNAS system) and a smaller 6TB WDMyCloud. Following the upgrade to 2017 all existing connections and backups continue to work, but I cannot change/add anything as (correct!) credentials are not accepted and result in a failed connection.

I did delete the smb key without success but will stop here as I am not experienced enough to comfortably mess with the registry etc. I do agree this feels like a bug. May I assume Acronis is giving this top priority? I am concerned that should I need access to a backup I can't because of this issue. I will submit an error report as well. Let me know if I can provide any additional info that would help the experts to understand/resolve.

What release of FreeNAS are you running?  Is your release up to date with the latest build?  Are your shares owned by a specific user?

I run FreeNAS 9.10 stable and to my knowledge I do not have this issue.  Can you further explain the you "cannot change or add anthing", how so?

I also run a WD MyBook as an NAS and I do not see this behavior there either, you are saying this same behavior exists on your MyCloud as well?

Wim,

You should provide feedback directly to Acronis through the app...reference this thread.

I want to put this out there as well.

I can't authenticate to my NAS when I'm booted into the system using the ATI boot ISO burned to CD. I see the NAS but authentication fails.

When I hear back from Acronis support on the ticket I entered I'll let them know about this as well.

Wim,

I ran a test with True Image 2017 version 5554.  Created an Entire PC backup and left all backup settings in default.  Selected destination as  my user share on my FreeNAS machine, selected desired backup folder at which time the application checked my credentials, authenticated, and granted access.  I then created a new subfolder for this test backup and proceeded with the Backup now button.  Backup ran successfully.

I did not try this to my WD MyBook as I am confident I would have the same result.  I cannot explain why some users are having issue here, there are a number of things that could be at root of the issue, I would suspect permissions are not set correctly or network settings are incorrect in some manner but short of trail and error not sure what anyone posting here should try.

The link below is a simple guide to correct setup of SAMBA shares on a FreeNAS system along with some user comments that may be of some help to you and others.

https://forums.freenas.org/index.php?threads/simple-example-of-how-to-c…

Enchantech,

Yes, I have provided Acronis feedback.

I also run FreeNAS-9.10-STABLE, no pending updates. Note that every other piece of software CAN authenticate and so could Acronis 2016. And so can A2017 if i run the backup jobs cretaed on A2016, they still authenticate. Furthermore, the same problem occurs with the WD-MyCloud.

So I don't think it is the result of the shares or permission structure on the NAS and it seems related to A2017: if a new backup job in A2017 is created it will not authenticate. But, for what it is worth: the relevant shares are Windows (SMB) shares with specific users permitted full access - auth's correctly provided to A2017. I will try to play a bit with the NAS shares, e.g. create a new one with public access see if that works, probably will. I still believe this is a bug in A2017. I also just noted an update to A2017 will try that as well.

Update: this A2017 update 1 was installed already, I am indeed running 5554.

What I can say is that at one time when I first configured my Samba shares on my FREENAS I had problems from time to time with authentication and that started in beta testing Windows 10.  After I recreated the shares as outlined in the link I provided the issues went away.  So in my case it was a configuration issue.

Hi @ All,

For those having problems with their NAS Hard Drives and using Windows 10, include your Windows 10 Build information. That is very important!

For the record I am using Windiws 10 Anniversary update 1607 version 10.0.14393.222 released 3 days ago.  The anniversary update was applied subsequent to the True Image 2017 Update 1 version 5554.  Additionally, I use a local user account for logon to my Windows 10 machines instaed of a Microsoft account as Microsoft wants users to do.

I have not had difficukty with backup/restore or any authentication issues since configuration of SAMBA shares as outlined in the link posted in post number 43 above to FreeNAS since Windows 10 initial release 10586.

I think it should be pointed out here that Windows Security has changed with the Windows 10 release, SAMBA versions 3 up, and there is a learning curve in network configuration with these changes.  Acronis True Image 2017 updated network security to conform with these changes.  These changes are in my opinion at root of issues now being experienced by users of the product.

The changes I mention here have to do with what is known as "Man in the middle" attacks which are not a problem in most home network environments but can be for mobile device users using public network access points. 

As a result of these changes Windows 10 does not allow unathenticated users, even Guest accounts for SAMBA share access.  A user account/password is required for login.  Additionally, users whom are using a Microsoft account to logon to a Windows 10 machine and are attempting to access SAMBA, SMB, or CIFS shares may be deemed by enhanced security protocols as a Domain user and require additional authentication for access. 

I am including a link here that discusses this situation in more detail along with some tips on configuring a Windows 10 user account and corresponding SAMBA share acount for access.

https://techjourney.net/cannot-connect-to-cifs-smb-samba-network-shares…

This definately must be a bug on Acronis related to Windows 10 anyversary edition.

I am running the following versions:

• Acronis True Image 2017 build 5554
• Windows 10 Pro Version 1607, build 14393.222

My Issue:

My scheduled backups are running fine, but I am not able to modify existing jobs or create new ones using my Seagate Black Armor. 

Everything was working fine, until I upgraded to ATI 5554.  I am able to access my NAS just fine from Windows with or without mapped drives.

My NAS drive space is at 85% and I need to modify my backup job to remove old backups and I am not able to do so now due to this progblem.  I keep getting the Enter credential window, and ATI is simply not able to authenticate my credentials.  I even created a new user on my NAS and same thing, browing with Windows and entering new credentials worked but not from ATI console.

Acronis must be able to duplicate this issue and relase a patch update.

Hi @ All,

For the record, I am still using Acronis Build 5534, because of a Bug with 5554 with Comments.

Anyway, I am running both Windows 10 Pro 32-Bit Build 10586 in a Square 19" Monitor, because Build 14393.222 and early builds from 14328 Insider Preview made changes to the Column Width, in order to help High Definition Monitors.

https://blogs.windows.com/windowsexperience/2016/04/22/announcing-windows-10-insider-preview-build-14328-for-pc-and-mobile/#hJq2Xqgih1Qi7Zhm.97

We fixed an issue where default column widths for Task Manager were too narrow on high DPI devices.
Read more at https://blogs.windows.com/windowsexperience/2016/04/22/announcing-windo…

I also have Windows 10 Pro Insider Preview 32-Bit Build 14936 with a Wide Screen Monitor. That operating system, has a problem with Mapped Hard Drives not reconnecting to the operating system when restarting the computer.

I also have Windows 10 Pro Insider Preview 64-Bit Build 14931 with a Wide Screen Monitor. That operating system, has a problem with Mapped Hard Drives not reconnecting to the operating system when restarting the computer.

I also have Windows 10 Pro 64-Bit Build 14393.222 with a Wide Screen Monitor. That operating system, does not have a  problem with Mapped Hard Drives not reconnecting to the operating system when restarting the computer.

The problem with Mapped Drives started with Build 14915.1000 and continuing with the latest Insider Preview Builds, which is why learning which Windows 10 Build on are on, is important. There is not a problem with Acronis but Microsoft.

The latest Insider Preview Build sees the Network-Attached Storage Unit, but doesn't reconnect the Mapped Hard Drives, They need to be reconnected manually.

Unless you run an Insider Preview Build and experience this issue, you may not have any idea of what I am talking about.

https://blogs.windows.com/windowsexperience/2016/09/28/announcing-windows-10-insider-preview-build-14936-for-pc/#e8DuI8KuCxwLhQP0.97

Authentication changes affecting connectivity to NAS devices and home file servers

After updating to the latest Insider Preview builds, you may have noticed that shared devices on your home network have disappeared from your home network folder. You may have also noticed your mapped network drives are not available. If you change your network to “private” or “enterprise”, it should start working again. For more information on this behavior change, see this Microsoft Security Bulletin.

Read more at https://blogs.windows.com/windowsexperience/2016/09/28/announcing-windo…

And I always had a Private Network.