Error 0x40014: Access to the file is denied

What is the destination you are backing up to?

Did you upgrade ATI or is it a first install?

Thank you for having a look at my issue.

The backup destination is a mapped network drive to a Windows file server. There is plenty of available space in the destination and no issue with write permissions to that share.

The installation is the upgrade license. However I did not have the old version (2015 in this case) installed. I simply supplied the license key to satisfy the upgrade requirement during a clean installation of 2020.

I would suggest running chkdsk on the source drive.  Given it is an SSD I suggest chkdsk (yourdriveletter): /b/x.

The True Image app scans drives for errors and if errors are found it will produce seemingly unrelated errors.

Adam, please check the backup_worker log for your backup task where more detailed information is written than in the default ti_worker log which is the source of email notifications.

The backup_worker log can be found at:  C:\ProgramData\Acronis\TrueImageHome\Logs\backup_worker\

Also check your antivirus software for any files being quarantined at the time of the error.

Here are the results of: chkdsk c: /b/x

Checking file system on C:
The type of the file system is NTFS.
Volume label is Boot.

A disk check has been scheduled.
Windows will now check the disk.                         

Stage 1: Examining basic file system structure ...
  1055744 file records processed.                                                         
File verification completed.
  9298 large file records processed.                                    
  0 bad file records processed.                                      

Stage 2: Examining file name linkage ...
  9558 reparse records processed.                                       
  1310666 index entries processed.                                                        
Index verification completed.
  0 unindexed files scanned.                                         
  0 unindexed files recovered to lost and found.                     
  9558 reparse records processed.                                       

Stage 3: Examining security descriptors ...
Cleaning up 13984 unused index entries from index $SII of file 0x9.
Cleaning up 13984 unused index entries from index $SDH of file 0x9.
Cleaning up 13984 unused security descriptors.
CHKDSK is compacting the security descriptor stream
Security descriptor verification completed.
  127462 data files processed.                                            
CHKDSK is verifying Usn Journal...
  40183888 USN bytes processed.                                                            
Usn Journal verification completed.

Stage 4: Looking for bad clusters in user file data ...
  1055728 files processed.                                                                
File data verification completed.

Stage 5: Looking for bad, free clusters ...
  40491138 free clusters processed.                                                        
Free space verification is complete.
Correcting errors in the Volume Bitmap.

Windows has made corrections to the file system.
No further action is required.

 499411967 KB total disk space.
 335883320 KB in 704047 files.
    384120 KB in 127465 indexes.
         0 KB in bad sectors.
   1179975 KB in use by the system.
     65536 KB occupied by the log file.
 161964552 KB available on disk.

      4096 bytes in each allocation unit.
 124852991 total allocation units on disk.
  40491138 allocation units available on disk.
 

Now we have something. Here is the contents of C:\ProgramData\Acronis\TrueImageHome\Logs\backup_worker\backup_worker_2019-09-09-04-53-20.0.log:

It seems that the software is connecting using the UNC path instead of the mapped drive letter and is therefore not connecting using the necessary credentials to get write access to the destination. Very misleading stack trace. The software should have thrown an exception when it saw that the backup destination was open in read-only mode (line 2). 

Now, what to do about it? I'm certain that I didn't browse to the share with the mapped drive right in my face. But then again, perhaps I'm insane. The only thing I know to do is to try creating the job again from scratch unless you wise gents know of a better course of action.

------------------

2019-09-09T04:53:20:387-05:00 22996 I00000000: >>> --id=10001 --action=browse --agent="Acronis True Image 2020 24.3.1.20770 Win" --archive="smb://the-brain/share/Backups/Acronis/Command-Center/Samsung SSD 840 PRO Series DXM04B0Q.tibx" --ar-loc-username="NT AUTHORITY\\Guest" 
2019-09-09T04:53:20:440-05:00 18000 I00000000: type=log; level=inf; message=ar#1: opening archive path="\\?\UNC\the-brain\share\Backups\Acronis\Command-Center\/Samsung SSD 840 PRO Series DXM04B0Q.tibx" in readonly mode;

2019-09-09T04:53:20:442-05:00 18000 I00000000: type=log; level=err; message=io: failed to open '\\?\UNC\the-brain\share\Backups\Acronis\Command-Center\Samsung SSD 840 PRO Series DXM04B0Q.tibx' (win_err=-2);

2019-09-09T04:53:20:442-05:00 18000 I00000000: type=log; level=err; message=io#1: failed to open "\\?\UNC\the-brain\share\Backups\Acronis\Command-Center\/Samsung SSD 840 PRO Series DXM04B0Q.tibx" (pcs_err=-8);

2019-09-09T04:53:20:442-05:00 18000 I00000000: type=log; level=err; message=ar#1: failed to open archive path="\\?\UNC\the-brain\share\Backups\Acronis\Command-Center\/Samsung SSD 840 PRO Series DXM04B0Q.tibx" mode=readonly uuid=00000000000000000000000000000000, err=-5022 (File not found);

2019-09-09T04:53:20:442-05:00 18000 I00000000: type=log; level=err; message=unable to open archive file (err -5022);

2019-09-09T04:53:20:443-05:00 18000 I00000000: type=retcode; value=5022; id=10001;

2019-09-09T04:53:20:444-05:00 22996 I00000000: >>> --id=1 --action=backup --action=cleanup --action=metainfo --disk-backup --agent="Acronis True Image 2020 24.3.1.20770 Win" --archive="smb://the-brain/share/Backups/Acronis/Command-Center/Samsung SSD 840 PRO Series DXM04B0Q.tibx" --ar-loc-username="NT AUTHORITY\\Guest" --source="\\local\\hd_gpt(12E367B5409269E8F2D5EDBE4DA416D4)" --exclude-wildcard="hiberfil.sys" --exclude-wildcard="pagefile.sys" --exclude-wildcard="$Recycle.Bin" --exclude-wildcard="swapfile.sys" --exclude-wildcard="System Volume Information" --exclude-wildcard="*.tib" --exclude-wildcard="*.tibx" --exclude-wildcard="*.tib.metadata" --exclude-wildcard="*.~" --exclude-wildcard="*.tmp" --exclude-wildcard="C:\\Users\\adam\\AppData\\Local\\Temp" --exclude-wildcard="C:\\Users\\adam\\AppData\\Local\\Microsoft\\Windows\\INetCache" --exclude-wildcard="C:\\Users\\adam\\AppData\\Local\\Mozilla\\Firefox\\Profiles\\*\\cache2" --exclude-wildcard="C:\\Users\\adam\\AppData\\Local\\Mozilla\\Firefox\\Profiles\\*\\OfflineCache" --exclude-wildcard="C:\\Users\\adam\\AppData\\Local\\Opera Software\\Opera Stable\\Cache" --exclude-wildcard="C:\\Users\\adam\\AppData\\Local\\Opera Software\\Opera Stable\\Media Cache" --exclude-wildcard="C:\\Users\\adam\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Cache" --exclude-wildcard="C:\\Windows\\CSC" --exclude-wildcard="C:\\OneDriveTemp\\" --exclude-wildcard="C:\\Users\\adam\\OneDrive\\" --exclude-wildcard="C:\\Users\\adam\\Google Drive\\" --exclude-wildcard="C:\\Users\\adam\\Pictures\\" --machine-id="5D4F1B58-ABFF-44B2-A286-BE9CAAECC09C" --resource-id="14483742-1710-4111-BE5C-3E8C338C5FB9" --vss-mode="vss" --backup-scheme="full" --keep-versions=1 
2019-09-09T04:53:20:445-05:00 18000 I00000000: type=log; level=inf; message=ar#1: opening archive path="\\?\UNC\the-brain\share\Backups\Acronis\Command-Center\/Samsung SSD 840 PRO Series DXM04B0Q.tibx" in append mode (create);

2019-09-09T04:53:20:448-05:00 18000 I00000000: type=log; level=err; message=io: failed to open '\\?\UNC\the-brain\share\Backups\Acronis\Command-Center\Samsung SSD 840 PRO Series DXM04B0Q.tibx' (win_err=-5);

2019-09-09T04:53:20:448-05:00 18000 I00000000: type=log; level=inf; message=pcs_sync_open(\\?\UNC\the-brain\share\Backups\Acronis\Command-Center\Samsung SSD 840 PRO Series DXM04B0Q.tibx) failed: 5 (pcs_err=37);

2019-09-09T04:53:20:448-05:00 18000 I00000000: type=log; level=err; message=io#1: failed to open "\\?\UNC\the-brain\share\Backups\Acronis\Command-Center\/Samsung SSD 840 PRO Series DXM04B0Q.tibx" (pcs_err=-37);

2019-09-09T04:53:20:448-05:00 18000 I00000000: type=log; level=err; message=ar#1: failed to open archive path="\\?\UNC\the-brain\share\Backups\Acronis\Command-Center\/Samsung SSD 840 PRO Series DXM04B0Q.tibx" mode=append uuid=00000000000000000000000000000000, err=-5002 (No access/permissions);

2019-09-09T04:53:20:448-05:00 18000 I00000000: type=log; level=err; message=unable to open archive file (err -5002);

2019-09-09T04:53:20:448-05:00 18000 I00000000: type=retcode; value=5002; id=1;

2019-09-09T04:53:20:448-05:00 22996 I00000000: >>> exit
2019-09-09T04:53:20:451-05:00 22996 I00000000: >>> exit

Adam, there appears to be several issues at work here, CHKDSK found and corrected issues with the file system which would affect your backup task, plus the backup_worker log potential issue with using UNC when you are expecting a mapped drive letter.

I am not sure that the latter is an issue as it may be that ATI is expanding the mapped drive to the full UNC path here, but this does raise the question about credentials?

Personally, I do not use any mapped drive letters to my own Synology NAS and therefore store no credentials for such in the Windows Credentials Manager.  The credentials I use for my backups to the NAS are for a user only known to the NAS with the required privileges to the folders where my backups are stored.

Adam,

Did you use Windows Explorer Map a network drive feature to setup your network drive?

A mapped drive in Windows uses a UNC path even though you do not see it.  Your log indicates to me that you do not have authenticated access to the drive/shared folder on the File Server.  Are you sure your sharing is setup correctly and that the mapped drive can be accessed outside of True Image?

Also, disconnect the mapped drive, and delete the credentials in the Windows Credential Manager. Reboot.

Can you then run the backup successfully in interactive mode (from the UI)?

I've been using that file server for many years now. It's a Windows Server 2012 R2 box that sorely needs an upgrade (it's on my list ;-) ). The drive was mapped using the normal mechanism in windows explorer. However, I do have to authenticate using different credentials because I don't have a proper domain setup (just a workgroup; another thing on my list). So if it is what it appears and ATI is expanding the underlying UNC path and hoping that the local logged-in user will be able to write to that path, it's in for a rude awakening. That's not a valid assumption to make.

I'll try fiddling with it some more tonight and get back to you all with what I find. But this is starting to look like a bug in ATI. We'll see though...

I do not think that ATI is assuming anything.  I use a Workgroup network, having 8 PC's all connected.  I also have 3 NAS devices on the network.  I have no problem currently in accessing any device from any device on the network currently and ATI is no exception.

Having said that, one of my NAS devices is a Linux based server computer running the FreeNAS OS which is based on FreeBSD.  I had issue with that device after Win 10 1809 came out and MS fully deprecated the SMB 1 protocol.  I worked around that for awhile by having SMB 1 running on my main PC but I did not do that for long as I knew it was only a matter of time before any support for SMB 1 would vanish. 

In trying to get things working I found at first that some of the issue was that SAMBA used NetBIOS for device discovery on a Windows network.  NetBIOS being a part of the SMB1 protocol stopped working when SMB 1 was removed.  This meant that a SAMBA device on a Windows network without SMB 1 enabled would not be discovered by Windows clients unless that client had SMB 1 enabled.

So my latest upgrade to the FreeNAS OS brought with it a partial fix.  Discovery by IP Address of the server is now working for Windows clients on the network.  Hostname does not.  SSDP discovery is said to be in the works for SAMBA but has not become reality yet.

All of the above caused permissions issues with the FreeNAS server on my network.  I cannot say if in your case such issues are at play or not but I encourage to investigate to make certain they do not.

Hoping the best for you.

I appreciate you sharing your experience and that is certainly a valid point to consider. However, even though Windows Server 2012 is "old" by tech standards, it does support SMB 3, which is what my Linux (Debian 10) clients use to connect to it (yes, the exact same share that is the target of this backup; SMB version stated explicitly in fstab connection parameters). I *assume* that the Windows 10 machine that is running Acronis is also connecting via SMB 3. But I will see how to go about verifying that and get back to you.

All in all, I have Windows 10, Mac OSX, and Debian 10 clients all connecting to that Windows workhorse server and everything is working perfectly. The only reason I really have to upgrade that server is simply that it's "old" and the main reason I haven't is because of that nagging voice in my head saying "If it ain't broke..." Literally, the only thing failing in my network right now is Acronis. That's why I'm putting this particular spotlight on it.

FYI: The chkdsk messages about "unused index entries" and "correcting errors in the volume bitmap" appear to be related to a known issue in the design of NTFS itself. These two messages refer to the same issue which is the result of applying custom security permissions to any number of files and/or folders and then returning them to a standard permission set. The resulting condition of the filesystem - which chkdsk corrects - is not ideal, but should not cause any issues with disk access nor does it indicate any sort of hardware problem.

More detail:

"This problem occurs because when Chkdsk is run against an NTFS volume,
Chkdsk.exe may report that security descriptors are in the database that are
no longer referenced by any file or folder, and that it is removing them.
However, Chkdsk.exe just reclaims the unused security descriptors as a
housekeeping activity, and is not actually fixing any kind of problem.

Microsoft has confirmed that this is a problem in Windows. Fortunately, this
error message is an informational message, and can be safely ignored.

All NTFS volumes contain a security descriptor database. This database is
populated with security identifiers that represent unique permission
settings applied to files and folders. When files or folders have unique
NTFS permissions applied, NTFS stores a unique security descriptor once on
the volume, and also stores a pointer to the security descriptor on any file
or folder that references it.

If files or folders no longer use that unique security descriptor, NTFS does
not remove the unique security descriptor from the database, but instead,
keeps it cached. Like any caching strategy, you want to keep the cached
information as long as possible because it may be used again."

-- Source: https://www.tek-tips.com/viewthread.cfm?qid=1603211

My reason for suggesting that you might face a permissions problem is because of the following entry found in the backup worker log you posted:

"2019-09-09T04:53:20:442-05:00 18000 I00000000: type=log; level=err; message=ar#1: failed to open archive path="\\?\UNC\the-brain\share\Backups\Acronis\Command-Center\/Samsung SSD 840 PRO Series DXM04B0Q.tibx" mode=readonly uuid=00000000000000000000000000000000, err=-5022 (File not found);"

I myself was getting a similar error and found the share permissions when viewed in Windows 10 Properties were Read only for the System Admin user.  So navigation to the share was working but writing to it was not.

You can see what protocol your Windows clients are using with PowerShell commandlet Get-SMBConnection  Look at the Dialect entry for your connection protocol.  Values shown are the highest negotiable for the connection.

Your Windows 10 clients should be using Dialect 3.1.1 with the 2012 r2 server.

Share Permissions are not SMB Protocol dependent, rather they are Share dependent. 

Another possibility is that one of your other client machine has an open connection to the server share.  Windows 10 has a single instance access to a share restriction in place.  So if you have another client machine that has the same credentials as your Windows 10 machine does and that machine has an open connection then TI will throw this same error.

I think I now what's really going on now. I still need to run some more tests to be 100%, but I'm pretty sure this is what we're facing:

When you map a drive in Windows, that mapping is for the current user only. So if i map it as user 'adam' and then ATI runs as 'Admiinistrator', it doesn't have access to the mapped drive. This is easily verifiable using PowerShell. Map a drive and then run two PowerShell windows, one as your logged in user and another as Administrator. Run "Get-PSDrive -PSProvider FileSystem" to list the drives in the system in both windows. You'll see that your user sees the mapped drive and Administrator doesn't. 

It's possible to fix this by using PowerShell commands to map the drive in the Administrator context and then everything is fine. What I'd like to do is exactly that and then run ATI and see if the problem goes away. I simply don't have the time tonight to do it though if I also want to get any sleep (other obligations... *sigh*).

Now, I don't know what that says about the single access restriction you mentioned. I've never heard of that and all of my clients are connecting with the same credentials and have for years without issue. So I would guess that restriction is only an issue if Windows 10 is the one hosting the share. When the share is hosted by a Windows Server, that restriction does not seem to be in effect.

Give me another day to hammer in this. Or if one of you wants to be a hero and try it out, that would be awesome too. Assuming we get the expected result, I'm not really sure what conclusion to reach regarding some closire to this. You could argue that it's not an ATI bug, but certainly the UI is misleading. Perhaps they should either only show mapped drives visible to Administrator or not show them at all and allow the user to configure the path and credentials in the app? I don't know. But I'm getting ahead of myself as it stands.

Prior versions of ATI were showing this behavior where the backup might not work when its destination is a mapped drive.

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

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

The recommended approach is to set the destination using the UNC path or to navigate to the CIFS SMB share through the network tree.

Acronis does encrypt and store the desired credentials to access the remote share with the backup script, and the list of the various connections in the registry for future use.

Computer\HKEY_CURRENT_USER\Software\Acronis\Connections\smb\

If you want to reset the connection and Acronis doesn't let you edit it (the edit connection UI doesn't always work), delete this key, reboot, launch ATI and it will ask you for the new credentials.

Clearly there's nuance in the UI that I have yet to appreciate. I'll poke around and see what I can do. If there's a way to specify a UNC path and provide credentials, then perhaps we can chalk this all up to user error. I'll check it out tomorrow.

Links to user network share restriction appear below.  This may not apply to you.   All depends on how you map the shared drive/location.

Same user share access

Error message

True Image installs runs under an admin account so your statement that a drive mapped by a user cannot be accessed by TI running as admin is correct.  This is a Windows limitation.  If you map the drive via UNC path then the mapping will appear as a new server share and TI should authenticate to it. 

The link below explains how to map a drive letter to a shared folder or create a network location in Windows 10.  If you follow those steps TI will not have any problem accessing the share.

Mapped network drive\location

I've got things working now. I would like to be able to report that I fully explored the issue and have a definitive explanation for everything. But due to time constraints, I had to focus on just getting something working. However, I'm reasonably sure I know what caused the original issue and most likely what the core issue is and what might be done to prevent other users from encountering this same problem. Here we go:

Issue: Due to the way Windows drive mapping works, ATI cannot access mapped networked drives created under any user account other than Administrator. So if a user-mapped network drive is selected as the target of a backup operation AND that mapping requires the use of credentials other than the local Administrator account, the backup will fail.

Solution: Create a new backup job. Instead of selecting a mapped network drive, select the UNC path and enter credentials, if required, in the relevant dialog.

Prevention: Considering the length and complexity of this thread, I think it is reasonable for Acronis to consider acting to prevent this scenario from occurring in the future. I would suggest that Acronis consider a change to the backup wizard that hides user-mapped network drives so that they are not selectable and direct users to browse to network shares via UNC path. The downside is that for some configurations the mapped drive may work (because the underlying UNC path doesn't require any special permissions) and some users may prefer this method, seeing it as a more user-friendly way of selecting the target path. But I would argue that differentiating the working from non-working cases is too complicated and simply not worth it. Also, it's not really that big of a deal to browse to the UNC path. Perhaps a little explanation dialog might be helpful.

* I don't know how to actually communicate this to the right people at Acronis. But I'm betting one of you does. So if you agree that this is a reasonable suggestion, please forward it along.

I don't know how to actually communicate this to the right people at Acronis. But I'm betting one of you does. So if you agree that this is a reasonable suggestion, please forward it along.

Adam, the easiest, simplest method is to use the Feedback option in the ATI GUI and copy / paste your conclusion from above into the feedback panel along with a link to this forum topic.

Will do. Thanks!

Glad to hear that you got it sorted.   Steve is spot on with his recommendation. 

Adam,

Thank you for documenting your issue and the resolution, and for sharing it here.

Best

Interesting.  I just tried defining a task to backup a file on a public share on a NAS.  Even though I have the UNC mapped, ATI used the UNC by default (although I suspect I could have overridden that).  But I also specified a pre-execution command that resides in the public share.  I did a Browse to access the command and ATI used the mapped drive letter.

Execution of the command filed with Windows "System error: '267'" ("The directory name is invalid." ).  I had to change both the command's path and the working directory to use the UNC.  Then execution was successful.

I think you may be opening up a whole other issue here. I haven't tried setting a pre-execution command. But it stands to reason that the mechanism used to invoke that may be entirely different from the way the backup target is accessed. 

If you really care to dig into this issue and figure out what's going on, I would suggest opening a new topic. 

If you don't really care and are happy to have figured out a workaround, then I suppose just let sleeping dogs lie.

Adam Takvam wrote:

I think it is reasonable for Acronis to consider acting to prevent this scenario from occurring in the future. I would suggest that Acronis consider a change to the backup wizard that hides user-mapped network drives so that they are not selectable and direct users to browse to network shares via UNC path. The downside is that for some configurations the mapped drive may work (because the underlying UNC path doesn't require any special permissions) and some users may prefer this method, seeing it as a more user-friendly way of selecting the target path. But I would argue that differentiating the working from non-working cases is too complicated and simply not worth it. Also, it's not really that big of a deal to browse to the UNC path. Perhaps a little explanation dialog might be helpful.

* I don't know how to actually communicate this to the right people at Acronis. But I'm betting one of you does. So if you agree that this is a reasonable suggestion, please forward it along. 

Adam, thank you for bringing up this idea! I'll discuss it with the RnD next week