This is all due to the remote server being a NAS, which led me to these fixes:

which were inconsistantly successful for me (and unsafe), so I'm moving production off this server.

I believe I have a permissions issue with ArcMap (10.2.2) geodatabases (file) on a remote file server. The error message is "Cannot acquire a lock." And it crops up in a number of (failed) processes:

  • importing features from another gdb to the remote gdb
  • running dissolve on features in the remote gdb
  • Auto Complete Polygon/Free Hand (in Create Features)

The difficulty in tracking this down is that there is no warning there are problems with locks until near the end of the process. Or in the case of Creating Features, no other operations besides Auto Complete Polygons will fail, making Polygons, Rectangles, Ellipse, and Freehand all work fine.

The only workaround I have found is to move the gdb to my desktop or our old (XP) fileserver (which gives full permissions). Following this clue along with the error message led me to discover that the remote gdb never opens lock files for the gdb or layer files when in use, only locks for files in use by editor (ed.lock). This image is from a local copy, and shows the three types of locks: https://drive.google.com/file/d/0B-pqTCgOoeO9M1FtcVZ6R2ltSDg/view?usp=sharing

Things which did not resolve the problem:

  • compact gdb
  • Run as Administrator
  • set scratch to local machine

Has anyone else had this problem and found a solution?

4 Answers 4


Your problem appears to be because of the difference of CACHE speeds between windows and NAS server. A regedit change will fix the problem

  1. solution from Esri for lock issue: Problem: Cannot acquire a lock while accessing data on a file share
  2. solution for slow openning: in the NAS control panel don't enable the advanced folder permesions, you can enable the windows ACL support (if you need to set permissions in win op and not in the NAS)

We have similar problems with the geo atabases on NAS. In our case it mainly depends on if several people work at the same time with the same geodatabase.

Normally it helps to

  1. delete manually all lock files and
  2. actualize the database by a right click and refresh (F5)

arcgis refresh

If that's not helping it usually the last step is a restart of ArcGIS.

Still we have for some users problem the geodatabases but usually the user who has create the database has the smallest problems.

  • Usually people leave it hanging with an arcgis crash, ctrl al delete shutdown, etc. Dec 23, 2015 at 1:40

In ArcGIS Desktop 10.8.2 in 2024 the issue occurs when editing an FGDB DC direct from a SSD HDD running win11 64x.
Only 1 instance of Arc open and no windows explorer for the FGDB folder etc

So as to not lose edits when in an edit session it is possible to export the layer of data or table to a geodatabase that is NOT the one being edited. It should export out fine with no loss of data.

It would probably be the same across network. This solution is a bit less intense than restarting arc which is a good way to lose all edits. Same for permissions, if nothing has changed than there should be nothing to fix.

If you don't have dependent table data you can even just copy all features and paste them to an SHP or FGDB. A much better solution particularly if you have hundreds or thousands of edits in memory.


If you have other MXD files open, using the same geodatabase, it will give you this error message. Close your other MXD's that are sharing that geodatabase and then try it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.