Failure to create backup -
I'm following up on a support chat I had with Acronis two days ago. Case # 02688682 with Joylean.
During that support chat I reported an issue where my system was failing to back up. The error message was:
"The backup has failed. Please close the application that may currently use the file [path]\file.tib."
Joylean worked around the problem by creating a new directory and a new backup process. She had assumed that the old backup process was corrupt in some way. However, after some additional investigation on my part I discovered that it actually had to do with NTFS permissions. I'd shared the folder and only given Full Access to the local user account. However, it looks as though the backup processes (TrueImageHomeNotify.exe and TrueImageHomeService.exe) run under the "System" user. Adding "Administrators" to the list of NTFS users fixed the issue but ONLY for backups on that local machine. Local machine fix steps below.
- Right click image destination folder and choose Properties
- Security Tab
- Edit button
- Click Add
- "Administrators" -> Check Names -> OK
- Full Control checkbox
I'm still trying to get other machines on my network to back up to the network share, but they are failing. I'm not sure how to resolve this. So any pointers on that front appreciated.
I'd like to make an enhancement request that the Acronis application more gracefully handle file access issues. An error message pointing to failure to gain write access to the directory would have made troubleshooting far easier. The application also seems to be timing out trying to access the directory rather than checking up front whether it has write access, as it takes a couple minutes before it fails.
The fix above worked only for
The support Joylean provided was polite, clear, and responsive. Thank you for your support. In turn, I hope I can make your product a little better for everyone else out there.
mrtsherman - please submit feedback to Acronis directly through the appication or your online account so they hear it. This is a usr forum so most of us are just like you. The Acronis techs do pop in from time to time, but the chances of them reading your post are less likely than if you submit feedback directly.
That said, Acronis will not be able to backup to any network shares that are not already accessible to those remote machines with Modify access via Windows Explorer. If any of your machines are using Windows 10, this has complicated network sharing even more with Windows 10 enhanced security. If using a homegroup, if any systems have left or rejoined, that can break the homegroup permissions. If any accounts have been converted from local accounts to Windows livemail accounts, that can also break the permissions for apps that had previously been setup for access.
1) Make sure that all of your remote systems have modify read/write access to the remote share in Windows Explorer. If that's not working for all of them, the issue is a local permissions/share issue that needs to be worked out first. Test them all by having them actually create some files and delete them on the remote share.
2) If successful for all systems in #1, you will need to provide those credentials in Acronis when the remote share is selected as the destination. In most cases, you will need to set the username as "domain/username". In a workgroup, the domain is equal to the computer name where the share is hosted from. Username would be any account on that system with modify access to the share.
3) Unfortunately, Windows file sharing may be complicated by having a mix of homegroup and/or local share permissions. Are you using one type or both?
As a test, I would create a new backup task and select the same destination you are currently using for your other task. Does it prompt for credentials? If so, after you enter them, and test the connection, is it successful? If so, then setup the rest of the backup test and run a backup and see if it completes or not. If it does, but the original tasks still does not, you can force Acronis to prompt for credentials again with a registry modification - see Enchantec's post for which key needs to be modified: https://forum.acronis.com/forum/114633#comment-342488
Right click on Windows start button and select Run. Type regedit. In the Windows Registry navigate to"HKEY_CURRENT_USER\SOFTWARE\Acronis\Connections" . Delet the key "Connections". Close the Registry editor and any other apps runing and reboot your computer. Attempt to run the the backup again but before you click Backup Now click on the destination and navigate to the Z drive folder location. Somewhere in that process a logon prompt should be displayed where you can enter the proper credentials.
Thank you for replying Bobbo. A little weird that an unofficial user forum is hosted under their domain name.
The client machine does indeed have read/write access to the server. The problem seems to be that the backup process runs using the "SYSTEM" privileges and not the user privileges. So although I can write to the folder as the user, the process running the backup cannot. Checking task manager, you'll see this yourself for the executable "TrueImageHomeService.exe".
I thnk your point #2 was my true sticking point. This ServerFault article also states the same limitations.
http://serverfault.com/questions/135867/how-to-grant-network-access-to-…
It looks like I need to give [pcname]\[username] NTFS permissions and that should grant the SYSTEM process read/write access to the directory.
I was able to resolve the issue by flipping my share and NTFS permissions around. I set NTFS permissions to "Everyone" and limited sharing to just the connecting user account.
I'll be the first to admit that network sharing in Windows is not my forte, so I may be incorrect on some things. However, this at least got me up and running.
Glad to hear it! Not sure which version of Windows you're currently using, but Windows 10 shares/permissions have been even more difficult to deal with. Microsoft finally addressed the issue in an update about a month ago and thigns have been easier, but still much different than previous vesions of Windows.