Backup fails with "Please close the application that may access the .*.tibx fille

The log simply shows what you have already found, that access to the external drive has been denied for some reason and therefore the backup task cannot proceed.

Did you actually try to write to the drive when it was in this state to prove it is not write protected?

It is possible that ATI checks the status of the drive at the beginning of the task and does not recognise a change in status if it occurs after that point.

Thanks for your reply Steve, no I didn't try writing to the drive until I had re-connected it, by which time it was obviously OK.  Will do next time the problem occurs - if there is a next time.  Just seems odd that with the configuration, (both physical and ATH )the same for months, two separate drives should become write protected within days of each other. Sounds like USB Hub, cable or port failing (?)

The Log file (attached) indicates that there is a problem with the file access ('disk is write protected' - it isn't) , but why only when running from the schedule? 

It would be interesting to try manually restarting the task when this error happens.  And, as Steve suggests, see if you can write to the drive outside of ATI.

There have been problems with earlier releases of ATI that resulted in this error but would always mention the name of a non-existent .tib file.  The design of .tibx support is different enough that I would not expect this problem to exist in ATI 2020.  (The error doesn't even exist in ATI 2020 when writing .tib backups.)

Sounds like USB Hub, cable or port failing (?)

If the ATI error message has any validity, this error would have to effect writing but not reading.  I would expect a hardware problem to effect both.  Are there any significant errors in the Windows Event log around time of the failure?

Patrick, thanks, I have tried to restart the task manually following the error, but that only results in the same error. Not been able to try simply writing to the disk yet.  The error does mention the name of a non-existing tibx file, I only wrote as *.tibx for brevity. 

Event log entry same time as ATH error reads:

Microsoft-Windows-DistributedCOM
Date:          02/03/20 12:30:03
Event ID:      10016
Task Category: None
Level:         Warning
Keywords:      Classic
User:          GROUCHO\Bob
Computer:      Groucho
Description:
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {2593F8B9-4EAF-457C-B68A-50F6B8EA6B54}
and APPID {15C20B67-12E7-4BB6-92BB-7AFF07997402}
 to the user GROUCHO\Bob SID (S-1-5-21-2969582974-668605749-2947170660-1002) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.
 

DrMopp,

Not sure your up for it but have a look at the "533629-180897.pdf" file attached.  It gives exact details on how to correct the DCOM errors although I am not confident that it will fix your issue.  Over the years I have been here I've seen threads about DCOM errors before with any number of suggested fixes.  Sadly none of them seem to work.  Many suggest that it is a design flaw in Windows that causes the errors, not sure I believe that one either.

The solution below comes from Microsoft Answers so I would have more faith in it than everything else I've seen.  It is very detailed but also very involved.  Hope it helps.

Thanks, Sorry the DCOM error was a complete red herring as I'd failed to notice that although the time matched the ATH error the date didn't !!!!  Off-topic I know but I had a problem following the attachment in any case as for many of the 10016 errors the APPID was 'unavailable'.  

DrMopp,

So, looks like the DCOM error is unrelated.  So I have two other suggestion for you.  This involves looking at Windows Registry using regedit.  If you are uncomfortable with that then disregard.

1. Go to Start > type regedit > hit Enter
2. Go to HKEY_LOCAL_MACHINESYSTEMCurrentcontrolsetControl
3. Look for key StorageDevicePolicies
4. If the StorageDevicePolicies key is available, select it > you’ll see a WriteProtect DWORD key in the right hand pane.
5. Double click WriteProtect > replace the Value Data 1 with a 0 (zero)

Note: step 5 above is optional if you are uncomfortable editing registry values however, if the StorageDevicePolicies key exists and the WriteProtect Value Data is set to 1 than this is the cause of your error.

The second suggestion I have is that you re-select the Target (external drive(s)) that exhibit this behavior in the TI app's backup task(s).  Simply click on the backup Destination icon for the backup task, navigate to the storage location you have previously selected and click on it to select it again, then click Ok.  The windows should become out of focus briefly while the app resets this location.

Thanks, looked at the registry solution but the StorageDevicePolicies key doesn't exist.  On trying to re-select the target location in ATH the message  "Previously created backup versions will not be shown in the Recovery tab of this backup. To recover them, first add them as an existing backup" appears, which obviously I can do, but since you didn't mention it, thought I would check first..

Yes, you would have to do that.  Generally that only takes a short time while the app resets the meta data locations for the files.

Sorry I haven't been back on this issue for a while but it seems it may be a hardware issue as two of the three disks (all three attached through the same powered hub) seem to 'disappear' on booting now, and only reappear after being removed and reconnected to the hub.  The Acronis issue would seem to be a symptom rather than the problem. Thanks all for your time and interest.

Yes, failed or failing hardware such as cheap hubs, cables, etc. can cause all sorts of problems.

True, but since one of the three disks has held up consistently in the same hub  without issue and the two that are giving problems are in SATA to USB 3 caddies (same make)  it's more likely the caddies at fault - and yes they were quite cheap! Though of course there's still the cables and disks but unlikely that two would fail simultaneously - either way Acronis is blameless!

Problem happened again last night, different disk. I tried, as Steve suggested, to write a file to the disk in Windows File Explorer and that returned the 'Remove Write Protection error.  After removing write protection with Diskpart all was well and backup ran. Any thoughts as to why an external USB disk would suddenly become write protected?

1. A virus can.  Scan the drive.
2. Drive is full or not enough room on drive.  Check available space on  disk.
3. A File on the disk is set as Read only.  Correcting that can solve the issue.
4. Consider modifying Windows registry.  Look for this key : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies  If the jkey exists, right click and select Modify and change the value from 1 to 0

Thanks for your response. However:-

1. I run Kaspersky virus scan daily with no reported issues. Will try another virus checker just in case once the current backup finishes.
2. There has been no change in the available space on drive between the backup failure and the successful one - the only action taken was to remove the read-only attribute (392MB free before backup which is c. 145MB)
3. The only files on the disk are Acronis tibx files - encrypted backups. The other disks containing only encrypted backups do not suffer from the same issue.
4. That key doesn't exist.

Grateful for the suggestions, but seems as though there is something else involved here.

Are you still using the same hub? Have you tried connecting them directly to the USB port on you computer? What about the caddies you mentioned? Are you able to take those components out of contention?

How did you remove the write protection on the drive to get it to work?  Did you use diskpart to clear a Read Only attribute from the drive?  If not you should try that.

@BrunoC as all had been fine for a few days I had not changed caddies or hub.  The disk giving a problem today is a different one so disk issues seem unlikely, and yes now I will be taking the hub out of the equation by connecting the disks separately as and when needed (only one USB 3 port on this PC). If that does not do it then replacing the caddies would be the next step.

@Enchantech yes that's exactly what I used to remove the read only attribute. 

Since this setup has worked without problems for months, and disks, caddies, cables, and hub have been static and without any change in environment, wouldn't that suggest it's more likely to be a software issue?

Disk corruption can cause a hard drive to become write protected.  Data encryption can cause the same thing.  Next would be malware.

Run chkdsk X: /r where X is the drive letter of the USB drive and see of that finds and fixes any corruption. 

OK I ran chkdsk on all three backup disks yesterday with noo errors found. I have also run both Kaspersky and Bitdefender virus checkers on all three disks with no errors.  Guess I need to see if I still have problems when not using the hub, and if so look at replacing the caddies.

My bet is that elimination of the hub will solve the problem.

Thanks , it will take some time to confirm whether that's the case because I'll only know if the problem occurs without the hub after a reasonable number of backups and using each disk.  The fact it hasn't occurred yet doesn't mean much as it was intermittent even with the hub.

Understood, USB hubs, because of their inherent cheap construction are known to cause issues with ATI.  This dates back years and more often than not once they are removed from the equation the offending behavior stops.

OK so, several backups on, minus the hub and just one 1TB USB external disk connected to a USB 3 port directly..  ATI backup fails this time because the backup file is missing.  On checking, the disk wasn't visible in windows explorer, although the power light on the disk was lit.  Moved the disk to another (USB2) port and it was recognised.  Faulty port? When looking in Device Manager with hidden devices showing, there were several instances of both USB drives and hubs even though no devices were connected. Once 'cleared out' and after a reboot the disk could be plugged in and was recognised. So it seems like the swapping out of disks caused this latest issue, due to the port 'remembering' disconnected devices, (which has caused me problems in the past , but surprised that it is still around).  Thoughts anyone? 

My thought is that I suspect your external drives report themselves to Windows as Removable devices.  In this case you would need to Eject the drive via the Windows Tray USB icon or Explorer right click on the drive context menu Eject option.

In doing so you are allowing Windows to dismount the disk which cleans up or removes the drive ID from the OS.  If you do not do that the result is what you have found, rogue left over device instances.

In some cases not ejecting removable disks can cause other issues as well.

I have a similar problem with backup failing with operating system access denied error. Backup writes to USB external drive. This backup has been running for over a year without issues until last week. Have scanned all drives for corruption and nothing. Run a complete virus scan, no issues. Fails on schedule or on manual run.Numerous other things attempted with no joy.

My anti-virus is Bitdefender and I’m suspecting it may have made a change to auto-play for security purposes. Windows shows auto-play as set properly. Need to investigate bitdefender more. Is anyone else running bitdefender or recently seen a change to auto-play where we are talking USB drives? TIA

Hi Earl, I run Bitdefender and a nightly ATI backup without any issues.  Do you have any warnings under 'Notifications' in the Bitdefender console about Autorun? You should get one with the option to fix manually rather than BD doing anythng 'automatically'.  I'm guessing you've probably read through the suggestions in this thread already, but do you use a hub or direct connection to the target drive?