Skip to main content

Network share credentials - where do I change them?

Thread needs solution

Hi,

I have been using the OEM version of TI 2014 where I could set login credentials for each individual share on a network under the "destination" tab. These credentials were persistent and worked if one of the target shares was used as a "replicated copy" as well.

 

I use a NAS share for images that has only one user account with write access, and that account is not a user on any of my PC's. This is to prevent the share being accessible in case of crypto or ransomeware attack etc. General users are read only. On TI 2014 this worked just fine.

 

This was the SOLE reason I selected TI 2016 over Macrium Reflect which I otherwise find more user friendly from a UI perspective and some features.

I decided to "upgrade" to TI 2016 to access the additional scheduling options etc and there is nowhere to enter these credentials.

 

I have tried double clicking the share, using the little '>' to the right of the address bar etc and can not find any location to add them.

I uninstalled my OEM TI 2014 prior to installing the TI 2016.

 

So my questions are:

1. Where or how do I enter these credentials in TI 2016?

2. As a licensed owner of TI 2016 can I install a full version of TI 2014? It's still downloadable. [answer = NO]

I'm not using UEFI or GPT (but I think TI 2014 was ok with that anyway?). [answer = yes]

3. is there a 3rd party front end for TI 2016.... the UI is unintuitive. Finding advanced options is plain painful!

 

 

0 Users found this helpful

Just a follow up...

 

Spent about 30-40 min online with Acronis chat support. Very polite and helpful - in fact after my ISP, Telstra and other recent CS adventures it was outstanding to deal with people who know the product and are helpful.

What i discovered is that having had TI 2014 OEM installed I already had credentials somewhere in my registry (SMB share related?) and thus TI 2016 was picking them up. It never asked for the network login details for the share I was using as destination for this reason. A problem because you cant confirm what credentials it has chosen.

I changed the user acount info for the share on my NAS and redid the backup plan to see if 2016 would request login info. It does. But only for the primary destination - not the replicated copy. If you need to use the replicated copy option you must select the share as the primary destination first to trigger the login request then change them over (select the share on the drive tree under network, then click the blue '>' in the top right of the path).

I found this to be the case with TI 2014 as well - except that 2014 has a button allowing you to select/enter new credentials in the panel with the destination drive tree.

THe fellow from support confirmed and agreed that there is no way to change the credentials once entered in 2016 either. A pita if you rotate passwords or such.

 

Outcome for me at this point is a request to have one of my licenses downgraded to TI 2014 (full version not OEM), so I can have all of the functionality I need.

My chat info with support is being elevated to their dev group apparently.... based on request to have addition of function to enter and set credentials for the destinations (like 2014). Hopefully they won't just do what some others have an opt to use the current windows login credentials or offer option for alternate user login. I think destination account details are much better and safer.

I think it should be fine when I upgrade to win 10 as well since it supports gpt and UEFI?

 

Thanks for passing along feedback to Acronis on this issue.  It has been brought up before and others have complained as well.  That's how things get fixed though so others are encouraged to do the same, report it!

Yeah, it just seems to be a really poor decision to allow login credentials for a remote/network share to be used but have ZERO control over them once entered.

 

TI 2014 has been the only program so far I have used that allows credentials on a "per share" basis without having installed credentials on the user account running the backup AND the ability to deal with the usr account having read only  access to the backup target (hope that is clear).

It suggests that TI 2014 is managing the credentials and any open network connections pre/post backup (I'm a bit hazy on detail at this point). But this is REALLY HELPFUL. 

NOT having manual control of what credentials are being used is a bad decision though.

 

Other programs seem to act more like a GUI on top of windows functions and create a bunch of problems when the user account does not have write access to the target share.

Of two other programs I have used, one allows credentials to be set manually on a per destination basis - but screws the pooch by having it labelled as "Alternate windows login" (people try an alternate local account which then fails as it needs the destination credentials not windows user login). It didn't play well though if you had read access to the backup target. THe only workaround to get things going ok with this one was to write pre and post scripts with "Net use" to terminate any open "read only" session to the destination share so that the backup could open the write access  connection to it (quite a mess really).

Another doesn't allow any sort of login credentials to be added (Memeo) so cannot work with network shares with restricted access unelss you already have open access rights thrugh your currently logged in account. A circumstance which is very poor in a world where data security is becoming an issue at odds with 'convenience'.  

Memeo support told me that my virus scanner's responsibility was to manage risk not their program.... I wrote back and told the rep he was naive if he thought that was the case. Security is about layered protection from social engineering through to things like share restrictions. Also, for a program marketed to work in small businesses etc it's ridiculous to have no capacity to enter credentials given that it may not be appropriate for every user to have open access to backup targets.

So I understand "average Joe" using Acronis or this type of software is probably happy as it works across his internally insecure network with homegroups and unrestricted shares etc..... right up until he gets hit with crypto or a worm that nukes his entire network from production machine through to online backups.

I don't run a domain setup so not sure how my issue translate across to people in that situaion.

I *think* going back to TI 2014 will be fine for me.

mgrobins, thank you for the feedback. Development team is aware of the issue, we will figure out a soluton. Thanks!

Thanks :)

I have already been in consultation with online chat support and they have been fantastic. There are a couple of other threads where this topic is discussed at the moment and some workarounds but it's good news that you are looking to fix it.

It's obviously not an issue for every user and I'm glad you still want to address it for those of us who need it :).

Few programs seem to do it well so I am ok with TI 2014 for now and will upgrade again once TI 2016 matures a bit (I'd prefer TI 2016 once I'm using windows 10, and for the full support you provide for it).

 

Cheers.

I'  not certain. I still use TI 2014 which is secure for me as the PC boots to do the backup and then shuts down. The backup share is only accessbile for writing at the time the Acronis backup is operatng as it logs in and opens the shares (so it is vulnerable in thie time frame).

I would love to see a proper implementation of share control by user  account so that a backup could be triggered to a share Acronis can log into but not the PC's other accounts, and then close the network socket after that backup such that other progams cannot write to it.

 

I will be going to TI 2016 soon if 2014 is buggy with windows 10.Im just building my win 10 SSD at the moment and will transition to is soon.

 

stna1981

Yes, 2017 has much better NAS control with credential updates that prompts for credentials if there are any connection issues when attempting to connect.  FYI - there is a current bug in 2017 5554 that causes a connection issue in Windows though when first setting up a new connection or attempting to edit an existing one (all from within Windows).  They have released hotfix patches for this though which will resolve this behavior until the next update.

mgrobins

Windows has a habit of holding onto network shares for as long as the Windows session is still active (there may be a specific time period that it finally drops, but I'm not sure what it is).  As a work-a-round, I suspect you could use a "net use" .bat script as a pre-command to briefly map the drive just before the backup runs and then use a similar "net use" .bat script as a post-command to disconnect the newly created mapped drive.  

Keep in mind that Windows sets a limitation of only one remote session (can't switch to different credentials), per remote device.  So, if you have other mapped drives or network shares (or are using Microsoft stored credentials) to access these on a NAS or remote share already, but want Acronis to use a different set of credentials to connect to the same remote device, it will fail - due to Microsoft limitaiton (older article for a different OS, but still applies even in Windows 10 - https://support.microsoft.com/en-us/kb/938120