ATI 2018 will not save to network share - credentials failed
I enter a full path to a network share, but when the credentials dialog is displayed, the path is different - it truncates the last couple of folders.
I have access to the full path at the top, but I do not have access to the truncated path in the credentials dialog.
Any ideas?
I haven't been able to get a mapped drive to authenticate either. I map a share to a drive share (e.g. "Z:") which has full R/W access. ATI18 still prompts for username/password (even though its already cached in the Windows filesystem) and refuses to authenticate to the ID/password of the shared drive owner.
In risposta a Rob, can you map the full… di truwrikodrorow…
Very strange - with a mapped drive letter, it does the EXACT same thing.
That Authentication dialog for the credentials is really broken.
I just bought the paid version and I can't backup my system - Grrrr....
In risposta a I haven't been able to get a… di truwrikodrorow…
@Bruce
Same here...
Please open a Support Case with Acronis Support for this issue and let them investigate in more detail with you.
Users having trouble here:
Insure that you are backing up to an authenticated share on your target device (NAS). If you have not setup a user account with password chances are you will meet failure in accessing a network share. Additionally, if you do not have any success using an IP address in your path try using the name of your target device as you would see in Windows Explorer.
Some screenshot illustrations appear below for reference
Explorer view of share:
Path in True Image 2018 Destination
Backup screen showing data to backup and Destination
Completed backup task shown under Activity tab for backup task.
In risposta a Please open a Support Case… di truwrikodrorow…
@Steve - I did open a ticket, but support is having me try all sorts of things that are not at all related to the issue at hand.
Try taking away authentication under one of the folders just above the destination folder. I bet yours fails too
@rob mason
Nope, still works fine. Reconfigured the same backup task moving the destination folder just above the original, succeeded.
I might suggest this, when you are prompted to enter the credentials enter your entire credentials both username and password even if those fields are already populated. This should edit the credentials in the application and allow connection.
I cleared/re-entered the credentials but it still does not work.
Note:
I do NOT have access to the path displayed in the dialog.
I DO have access to the path I entered at the top of the page.
I just have no idea why the dialog is displaying something different than what I entered??
What are you trying to backup to? The corp.wan looks to be a corporate network possibly, is it? If so you need to talk with your network admin and see if permissions can be set to allow you to backup or write files to the location you are specifying.
I enter a full path to a network share, but when the credentials dialog is displayed, the path is different - it truncates the last couple of folders.
Aren't network credentials at the "share" level? If that's the case, it makes sense to me that even if you enter the full path Acronis would still need to validate at the share level. (I could be ware off base there, but that's my understanding.) That would not explain the problem validating, but it would explain the path displayed by ATI.
Patrick, how long is your 'full path to the network share'? This may be a limitation on the path length?
Steve, forum problem there. In that first paragraph I was trying to quote from Rob's initial post. I don't have a problem (related to this thread, that is :-) ).
Patrick, no problem, wish they would bring back the
sss
options again as we had in the old forum as that made it a whole lot clearer when anyone was quoting from an earlier post in the thread!
I think it is just a view perspective. In the credentials screen it appears to truncate the path as you say but I am certain that is due to the fields not being long enough to display the full path even though that is the location to which you navigate to. I see the same thing as you do in this respect.
In my case I have user accounts established directly beneath the root account of my NAS. So the core OS files of the NAS (Linux based) is not accessible to any user. Users only have access to folders within a user Group so this provides a level of protection from the OS.
Most upper tier NAS devices use this method of access/protection like Synology, Thecus, Netgear, etc.
Western Digital NAS (at least MyBookLive and MyCloud) have the same effective arrangement but the implementation seems different. Shares are allocated directly beneath Root but are not intrinsically associated with a user. Any defined user can be given read or read/write access to any defined share. The GUI-accessible admin account defining this access has no visibility to the contents of the share; access is granted or denied at the share level. (The single SSH-accessible account, if enabled, has access to the OS.)
WD uses a stripped down arrangement of a Linux based Server such as I run. I to have to access root using an SSH logon.
The rules are essentially the same. The biggest difference is that I can create User Groups which have permissions only in that group. I do not use that but is there if I choose to.
So authentication is at the user account level and shares created for that user account. Since I am the administrator for the Server I have created user account under my account which I can administer but those users can only access the shares setup for their own account.