error -1017 insufficient permissions on full volume restore

[DaveD]

Windows 10, Retrospect Desktop 17.5.2.103. Hundreds or thousands of these 1017 errors on a full volume restore from a local USB attached backup drive.

This was on my MS Surface Pro 6 after backing off from Windows 11 to Windows 10, reinstalling Windows 10 from scratch from the SP6 recovery image thumb drive, then installing Retrospect. I tried it several times, with a massive waste of time in the effort. So I finally did a complete reinstall, which after several days of getting to it when I could, is now finally complete. The Activity Monitor histories and logs from those attempted restores are gone, of course, since the reinstalls obliterated them. 

I did lots of online searching for solutions to this problem and came up empty handed.

I did have to recreate the catalog for the first attempt (and I placed it on the backup disk), but have since used this catalog many times to get to individual files on the backup, so it is working properly and includes the snapshots.

Retrospect installed in its usual manner and the restores were running from my ID, which has administrator privileges. If I remember right, I even separately started Retrospect with administrator privileges.  

I've been using Retrospect Desktop for probably over 20 years now, ever since it was bundled as a freebie with an USB drive. Up to this time I have never lost a single byte of data, having successfully restored corrupted files and a couple of times a corrupted or dead C drive without problems. Keeping my data and my operating systems is very important to me, and it appears now that I have lost that capability with Retrospect. On my desktop I have always used two USB drives for my nightly backups, swapping one to an offsite location on a regular basis. I don't do this on my SP6, as I don't keep essential data there, but this problem tells me that I may have some concerns about being able to recover my desktop if the need arises.

If I can't solve this problem with some help from Retrospect and this forum, I feel that it is time that I move on to an new backup solution!

[mbennett]

When you search the KB on-line, make sure you search for -1017 and not 1017.  There's a difference, don't ask me why. I would contact support for help on this one. This is also documented on page 440 of the win.pdf user manual.

–1017 (insufficient permissions)

This error indicates that Retrospect was not able to access a volume during the backup operation.

This can happen when doing a scripted backup of a volume via Microsoft networking rather than a Retrospect Client.

Permission errors can occur under the following conditions:

• When the script was created you were logged in as user X. At the time of backup you are logged in as user Y who does not have permission to connect to the source server.

• When the script was created you were logged in as user X. At the time of backup you are not logged in.

This error can also occur when backing up to or from mapped network drives. If you receive this error when running scripts that involve mapped network drives, it is because the Retrospect Launcher service (the service that allows Retrospect to auto launch) needs to be configured to log on to the drives as a user with the appropriate privileges.

See the Retrospect Knowledgebase ( www.retrospect.com/knowledgebase) for information on how to avoid -1017 errors in all these situations.

[DaveD]

mbennett, thank you for your response. However, none of the conditions stated above or in the user guide pdf apply here. No script; a full restore from the menu. Retrospect was right out of the box. Locally attached USB drive. No networking. Administrator privileges. The backup volume worked fine later on for restoring individual and groups of files as I rebuilt the Windows environment. Per the only entry that I could find that was close to being relevant in the knowledge base, "Can't use Open File Backup for Drive C, Error -1017 Insufficient Permissions", I could not get to the Windows Event Viewer because, of course, the device would not reboot after this restore. I do use the Event Viewer as needed to help diagnose issues. And so forth...

The problem here is that when a full restore is required for any reason, it very often has to be from a fresh OS install and a fresh Retrospect install. If there are no problems with the backup drive, it should work. I check all backups, both full and incremental, to make sure that there are 0 errors and 0 warnings. I send an email to myself every night after the incremental backup, and inspect it every morning. I also backup my data alone weekly to the Wasabi cloud storage site, using Retrospect. 

It is very troubling when something as important as this that should work doesn't and there are no alternatives. So I ended up spending many hours rebuilding a fairly complex Windows installation to something similar to what it was. If I had to do this with my Windows desktop, it would be a real challenge.

Thanks again for your response. If you have any more ideas, please let me know. In the meantime I will try to get some help from Retrospect. I really don't want to dump Retrospect, but may have to.

[DaveD]

I emailed Retrospect support about this problem and got a response from Robin Mayoff almost immediately. She has been very helpful with several emails. It turns out that there was a big OOPS! on my part. I MUST boot the computer from a Retrospect Disaster Recovery boot disk to do a full recovery. Recovery cannot be made from a running system. I simply forgot that requirement, but it is obvious that I did that the last time I did a full recovery, sometime about twelve years ago, since I have old recovery disks in my collection. 

However, the recovery process has become much more complex since the last time I did it and I would like to test the process on one of my Windows devices. But there is no way to test it without doing an actual complete recovery. I'm sure that it all works OK if done properly; I'm just not too sure about my ability to get through it all, including building the recovery thumb drive or disk and actually doing the recovery. Robin suggests using VMware, but I have never set that up and would like to avoid that if possible. 

I take back what I said about possibly going to another backup program. It has become very evident while working through this problem that I should stay with Retrospect. Retrospect still gets great reviews, it fits my needs, support has been outstanding, etc. It is known to be very complex with a difficult learning curve, but except for my poor memory about details, I understand it conceptually pretty well.