Select to view content in your preferred language

Cloned Python environment at ArcGIS Server 11.2+

1634
3
12-13-2024 01:37 PM
AlinaTaus
Frequent Contributor

Please we aware that ESRI's latest documentation on how to deploy third-party Python packages with ArcGISServer omits a very important step. In order to create a clone that ArcGIS Server will have access to, you need to make sure that the clone is created under the ArcGIS Server account. This bit is specified in earlier documentation (for example, see the  documentation for 11.1) but seems to have been removed starting at 11.2.

I only wanted to mention it here to hopefully save someone else from having to go through a bunch of unnecessary troubleshooting. After a week+ of testing we reached out to ESRI tech support and they had us create a clone under the ArcGIS Server account which fixed our issue. It was confirmed by the ESRI analyst that this is still a requirement  (we are running Server 11.3) despite the fact that is not mentioned in the current documentation. 

I have reached out to ESRI through the Feedback link and suggested they update the documentation as well. 

 

 

3 Replies
WilliamHarper10
New Contributor

Our team struggled with this as well. Our approach was to explicitly add Read/Execute privileges for the ArcGIS Server active directory service account.

My best understanding is that in Windows, files generally inherit privileges from their parent container (at least where inheritance is enabled). However, when you create or update a Conda environment, it isn't simply creating or updating files in that \arcgispro-py3-clone directory but it is moving a bunch of files back and forth between different directories and executing other installation scripts. Lots of those files that get copied into the clone directory have the privileges of their parent container which do not include privileges for that service account. I found an interesting post on stackoverflow exploring similar issues. Essentially, the AD server account couldn't use the cloned environment because it didn't have access to some of the site packages and libraries.

To remedy this, I created a simple batch script that applies those privileges to the clone directory:

icacls "C:\<clone_directory>" /grant agserviceaccount:RX /T

One of the limitations to this approach is that any time you change that Conda environment, you will need to update permissions. It does, however, allow any user to create and maintain environment for ArcGIS Server. Hope that helps!

AlinaTaus
Frequent Contributor

Thanks @WilliamHarper10, great workaround! I wish someone from ESRI would chime in and offer their opinions on this. But in the meantime, glad you have a solution!

0 Kudos
gprince
Occasional Contributor

i spent some time on this, by default conda downloads the pkgs to %LocalAppData%. This results in folders and files that inherit limited permissions (eg excludes `NT AUTHORITY\Authenticated Users`). conda then copies the files to the destination environment and maintains their permissions.

To fix this icacls approach described above by WilliamHarper10 appears to work.

Another approach is to have pkgs get extracted and staged in a folder that is not %LocalAppData% so they inherit access permissions for the system's users.

below is a "Python Command Prompt" session which produces an environment that is accessible and useable to all the system's users

SET CONDA_ENVS_PATH=c:\envs
SET CONDA_PKGS_DIRS=c:\envs\pkgs
mkdir %CONDA_PKGS_DIRS%
conda create --clone arcgispro-py3 -n clone1 --no-shortcuts --pinned

 

0 Kudos