Lock errors on NAS, none on Windows Server

[mattwilkie]

Hi Folks,

We've run into a very frustrating and hard to pin down problem writing certain kinds of data to our NAS devvice, a QNAP TS-879U-RP, firmware v4.0.5. I'd be extremely grateful for any light you may be able to shed on the issue, which is:

Certain operations from ArcMap always fail when the destination is on the NAS, and always succeed when the destination is a local drive or Windows Server 2003 (x64). We've replicated this from 3 different client machines (albeit all Win7x64), and from 3 different user profiles. We've disabled oplocks on the shares from the QNAP admin console, to no avail.

How do we troubleshoot this?

The application: ArcMap v10.2.1 (first noticed at 10.2. Not sure about 10.1).
The operation: Feature Class To Feature Class (Conversion)

Details from Arcmap results pain:

    Executing: FeatureClassToFeatureClass Z:\source\simple_box.shp Z:\out\default.gdb from_Arcmap_nas_no_oplocks # "Name "Name" true true false 60 Text 0 0 ,First,#,Z:\source\simple_box.shp,Name,-1,-1" #
    Start Time: Wed Feb 05 10:05:16 2014
    ERROR 000210: Cannot create output Z:\out\default.gdb\from_Arcmap_nas_no_oplocks
    Invalid function arguments
    Invalid function arguments
    Cannot acquire a lock.
    The table was not found. [from_Arcmap_nas_no_oplocks]
    Failed to execute (FeatureClassToFeatureClass).
    Failed at Wed Feb 05 10:05:18 2014 (Elapsed Time: 2.04 seconds)

Interestingly, the same process run straight from a python command shell works (see attached). This leads me to think QNAP is treating the desktop application, ArcMap, and the sub-shell geo-processing operation as two different users/machines. Or something.

I've contacted Esri Tech Support, and we've gone through a few rounds on it, but essentially the response is: since the operation is fine on Windows Server and fine on the local machine, it's not their application, and thus they're not in a position to do anything about it.


Other operations which we've had fail but are harder to narrow down into a simple recipe like the above are:

• "Failed to past feature_class_name. Cannot acquire a schema lock because of an existing lock" when copy pasting a feature class with a relationship class from one file gdb to another


• "Could not load data from the data source. If you can correct the problem, press the refresh button to reload the data. Possible problems can include bad network connection, invalid field, etc. Cannot acquire a lock. Cannot acquire a lock." when running Calculate Field on a shapefile

I'd really like to solve this, as it's a deal breaker for the device. If we can't rely it on for our bread and butter application, out the door it goes (but I like the qnap!).

[KaiTohinaka]

We are experiencing the same issue. When using the field calculator or adding a field to an attribute table we get this message:

"Could not load data from the data source. If you can correct the problem, press the refresh button to reload the data. Possible problems can include bad network connection, invalid field, etc. Cannot acquire a lock. Cannot acquire a lock."

This only occurs when the file source is on our NAS server. Things stored on a local drive or our other servers work fine. This has been replicated on several of our machines, since moving to a new NAS drive a couple months ago. We did not experience this problem with our old NAS server.

Any insight would be appreciated.

[ValentinWittich]

Same error message for us.

We're working a windows domain environment on a samba4 server. It seams like that the error message doesn't appear when you are working with the domain admin rights. Normal user (with full edit rights) experience the problem regular though not always. I could narrow the problem down, seems like it appears a little randomly too.

Regards Valentin

[mattwilkie]

I didn't get notification of your reply. I thought this message had gone to the void; sorry for not acknowledging!

[Anonymous User]

Matt,

Have you tried disabling oplocks from the client end (windows)?

Configuring opportunistic locking in Windows

[mattwilkie]

I didn't test disabling oplocks from the client side.

We've now restored the NAS to factory defaults a couple of times, and upgraded the firmware twice. I can't replicate the issue any more, but the environment is not the same so it's not a true clean bill of health: we've pulled the unit out of production, so it's not being hit by up to 50 clients at a time. e.g. If the issue was because of load it's not being triggered any more.

We've kept the unit out of production because the performance is markedly poorer than when we first got it, about 25%, and I've spent weeks trying to figure out what is going on without success. Time to give up and move on to my real job: GIS, not sysadmin.

[mattwilkie]

In case it helps anyone else track this down, here's the test data and recipe for producing the error, when we first encountered it: ENV.359_2014-Jan-28.zip - Google Drive

[LCMMMCE]

This fix seems to have provided solution:

http://support.esri.com/technical-article/000012722