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:
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:
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!).
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:
Code:
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!).