Hello Enterprise Community,
Im hoping you can help me with a problem. My client has a distributed Enterprise platform on 4 VMS (one each for Portal, WebServer, Hosting Server, and Data Store) that we just got stood up a few months ago with ESRI's help. I need to upgrade the Enterprise platform from 11.2 to 11.3, and first need to run the Webgis DR tool to back everything up. I have ensured there is a shared drive accesible on all 4 VMs and I have read and write privileges to the drive. When I run the WebgisDR tool in the Portal VM, I keep getting the error:
Cannot access the location \\shared_drive\ArcGIS_backups\backups. You must ensure that user account running the WebGIS DR utility has read and write permissions to the specified location \\shared_drive\ArcGIS_backups\backups.
As you can see, I have the folder location appropriately named with the right backslashes. I have worked with ESRI tech support and my client's IT support, and no one can figure out why this error keeps happening. I appreciate any input you can give.
Thanks,
Natalie
Solved! Go to Solution.
Can you try this \\\\shared_drive\\ArcGIS_backups\\backups in webgisdr properties and see if this helps.
Hi Sunnywaygis,
In the webgisdr properties file, the path does have the extra back slashes like you suggested. When the file is read, and the error is reported, it shows what the computer is reading as the path (without the extra backslashes) which is how I know the path was input correctly in the properties file.
\\\\shared_drive\\ArcGIS_backups\\backups (in properties file) --> \\shared_drive\ArcGIS_backups\backups (when read by the computer)
Thanks,
Natalie
Hi @DryCreekEng
Many responses in this thread suggest checking service account permissions. However, your error indicates it is the user account running the webgisdr tool that lacks sufficient permissions for the UNC path. This account is likely the one you use to log into the Portal machine.
While it's important to ensure that the service account for all Enterprise components have access to the shared path, this specific error points to the user running the webgisdr utility (i.e. whatever account you have used to open command prompt to run the utility).
I suggest double-checking the permissions of this account, or running the webgisdr utility using a different account with appropriate permissions, such as the Portal's service account.
Read/write permission errors can also be a symptom of exceeding maximum file path in Windows. If the local path of your UNC path exceeds 260 characters, you may experience these types of errors.
Good luck.
Timo
UPDATE - Just got out of a 2-hr ESRI tech support meeting, with no resolution in sight. The conclusion of the meeting was that the shared drive that was created for all VMs to access is located on Azure in the cloud, which may be the issue with the sharing error. We made sure each VM (portal, hosting, web, and data store) is using the same domain and service account, and gave the domain and service account full privileges on all ESRI folders on each machine that the webgisdr tool may access. I'll keep you all posted on any updates.
Natalie
UPDATE #2 - Working with ESRI tech support and the IT department, we finally got Webgisdr to run. These are the steps that made it happen:
1. Within the ArcGIS Portal VM, created the backup and temp folders on the C: drive. To create a shared folder that is accessible by all VMs, right-clicked on the backup and temp folders --> Sharing --> Share. This creates a network path to each folder that is accessible from all connected VMs (Hosting Server, Data Store, Web Server). Used the created network paths in the Webgisdr properties file as the locations for backup and temp.
2. Went in to "Services" (type into windows search bar) for each VM and made note of the "Log On As" user name for each ArcGIS system (Portal, Server, etc). Noticed that it was logging into Portal as a Local Administrator (./yvadmin), not a Domain adminstrator (yvadmin@google.com). Logged in as the Domain admin in each VM.
3. In the Webgisdr properties file, had to change the very last line for Portal PKI properties to True.
After all this, it finally ran. Thank you all for your input along the way of this journey.