There is a nasty little bug that sometimes causes Backups (and any attempted Restore) to fail on a workshared project.  The way to avoid this problem is so simple that it should probably be implemented on all workshared projects in your office:

check Regenerate if view/sheet is not up-to-date.  This will create a thumbnail for the non-opened view to be included with the initial backup version and eliminate the error message when saving the backup version.
Cannot Restore Backup Version an Unknown Error Occurred – The Revit Clinic

However – if you have already come across this problem and it is too late to check the above box … you may be able to get the Restore to work IF you reinstate an appropriately named preview.xxxx.dat file into the _backup folder.  Its worth a try if you are struggling to recover some important data.

I just became aware of an issue that I wanted to pass on to you all right away.  Workset1 is special.  It should never be renamed, because it can lead to fairly serious problems down the track, including the This action has caused deletion of non-editable workset: issue.

So you should make it part of your Revit standard that no one can rename Workset1 – ever.

As usual, this is something that Steve already knew, and already told us.  Thanks Steve!

One other habit I have is to never rename Workset 1 because Revit won’t let us delete it. It’s the “original” workset and Revit just doesn’t let us delete it.
Revit OpEd: Delete a Workset’s Contents?

An old discussion on AUGI also touches on the issue:

2009-04-16, 12:27 PM
I just followed Shruti’s instructions and got the same error. For me it says I am deleting “non-editable Workset ‘Workset1’ ” Any other ideas?


You can increase your productivity by opening Multiple Instances of Revit when working on the same Central file. This is particularly useful if you want to set one instance to render a view, and continue modelling or drafting in the other Revit instance.

This is how to do it:

  1. Open Revit, and open a local copy of the Central file. This instance will be using your normal user name (eg. Luke).
  2. Open another instance of Revit. Click the ‘R’ button, and go to ‘Options’.
  3. Under General, type a different Username into the applicable box (eg. Luke-SECOND)
  4. Click OK.
  5. In this second instance, open another local copy of the Central file. This is done by navigating to the Central, and then ensuring that the ‘Create New Local’ box is ticked before opening the Central.
  6. You now have two instances working on the same Central file. You can test this by ‘Synchronizing’ each instance.

If you have Worksharing Monitor installed, open it up and have a look at the two instances. You should see something like that shown below:Please note that you will need a decent PC to take advantage of this ability. It will be particularly useful if you have 4 or even 8 processing cores available.

We use a Netgear ReadyNAS Duo as our fileserver. Recently we started to experience some annoying and disturbing error messages, such as:

  • Access to {path}{CentralFileName}-backupeperms.dat was denied
  • Encountered a hardware I/O error while accessing {path}{CentralFileName}-backuprequests.dat
  • An unknown error occurred while accessing {path}{CentralFileName}.rvt

This resulted in some loss of work and lots of annoyance.
I discussed the issue with our local reseller and they basically recommended I stop using the NAS and use a different share. But I didn’t want to do that! However, it did seem likely that the problem was with the NAS. I played around with some settings in the NAS setup…and I think I found the answer. It was to do with ‘oplocks’. I needed to disable the oplocks for the share, and the problem went away! How do you do it?

  1. In the Netgear ReadyNAS Duo ‘Frontview’ administration page, go to the ‘Shares’ page.
  2. Go to the ‘Share Options’ for the share you are using to store Revit Central Files.
  3. Scroll down the bottom to ‘Opportunistic Locking’ and disable the ‘Enable oplocks for this share’ tick box.

What are ‘oplocks’? According to the utility:
Opportunistic locking (oplocks) can enhance CIFS performance by allowing files residing on this ReadyNAS to be cached locally on the Windows client, eliminating network latency when files are repeatedly accessed.
This definition indicates that oplocks could certainly have caused this issue. Since disabling the option, we have experienced none of the aforementioned errors.
Have you experienced this problem? If so, I hope my solution helped you.
Also, it looks like I haven’t been the only one with an issue like this:
“Specific applications known to exhibit this behavior include Solidworks and AutoDesk Revit, as demonstrated by your experience.”

EDIT Associated issue may result in error such as:
This issue was with a user not being able to write to a particular file that Revit uses to maintain the state of the central file.


First off, if you are working with Central/Local Files and Worksharing, then I encourage you to head over to Autodesk Subscription, login and get the Worksharing Monitor.

Then, open Revit. Go to the ‘Add-Ins’ tab on the Ribbon, and under the ‘External Tools’ you will find the Worksharing Monitor.

Once you go into the Worksharing Monitor, click the ‘System Performance’ button and a handy little utility will pop up. Enjoy!