Mapping network drive confusion

Hello everyone. I am trying to map a network drive on the server where our ignition service is hosted. Here is what I have in the ignition.conf:

# Wrapper For Mapping Network Drive - For Drawing Manager           #	                            
# Drive Information
wrapper.share.1.location = \\\cad\cad2\drawings2\ = M:
wrapper.share.1.type = DISK

# User Information To Login To Network Drive
wrapper.ntservice.account = Domain\user
wrapper.ntservice.password = AReallyStrongPassword
wrapper.share.1.account = Domain\user
wrapper.share.1.password = AReallyStrongPassword

#How Often To Retry Server Connection
wrapper.share.1.startup.max_retries = 2

# What Interval (Seconds) Between Retries:
wrapper.share.1.startup.retry_interval = 10

Here is the script code I am running:

import os
	input_path = "M:\\\\cad\\cad2\\2"
	dirList = os.listdir(input_path)
	for fname in dirList:

I keep getting an error that states: OSError: [Errno 20] Not a directory: 'M:\\cad\cad2\2'

I've tried different varations of the path in the input_path and have not been able to resolve the issue. YES I DID RESTART THE SERVICE AND I MAPPED THE NETWORK DRIVE WITH A MATCHING LETTER FOR THE WRAPPER DISK. I think my issue has to do with the wrapper, I'm not entirely sure if I need to input the ip address, as I've seen so many others not use an IP address. For example, I'm using \\cad\cad2\ and I've seen others use \cad\cad2\

If the map is correct, M: should already point to \cad\cad2\drawings2\.

example: M:/myFolder maps to \cad\cad2\drawings2\myFolder

Also, you may need to run the service under a user that has access to the folder.

Yeah we are using an account from corporate, an account that has full access to the files and folders. But what do you mean by run service under a user that has access to the folder?

Here's what I have and I hope its of help:

The Drive letter is M:. it has it's own IP. I'm not really sure what drawings2 but I'm assuming it's the shared drive name? Is any of that throwing it off?

This is what you have in ignition.config
wrapper.share.1.location = \\\cad\cad2\drawings2\

If you want to match your windows mapping, use \\\cad\cad2\

The Ignition Service runs using a user of some sort. Perhaps the user running the service does not have access to the path.


What I have in the wrapper: wrapper.share.1.location = \\cad\cad2\drawings2\ is the exact path, but I'll match the windows mapping and get ahold of corporate so that the account on the server can also have access. I appreciate the help.

We will have to apply the changes today and restart the service at the end of shift. I'll either get back to the form and give this the solution and a big like or come back for more headaches :sweat_smile:

Keep in mind that, if your connection the mapped drive breaks, it won't be re-established until the gateway is restarted. Similarly, if the target server is unavailable when the gateway is restarted, the restart will stall for a bit trying to map the drive, before failing.

Mapping drives via the wrapper is a kludge, and is not suitable for production use. IMNSHO.

Run the gateway service under a user account that naturally has access to that network location, then use UNC paths (complete location, not a drive letter) in your Ignition scripts. This will be reliable--it will automatically recover if the target server has trouble.


Ok, I'm not sure how to run the gateway service under a different user. I'll google and look through forms, but if there is some documentation please point me in that direction.

Go to Windows Services, and edit the Ignition gateway service. Change the default "LOCAL_SYSTEM" user to something with network privileges. You may need your IT to set up a specific domain user for this.

1 Like

Ohhh, okay. I'll just have the IT team grant our account access to the shared drive. I appreciate the help guys.

Will I foresee any issues using a different account on the service other than the "LOCAL_SYSTEM" As far as I'm aware nothing we've done is tied to the service. Most of our work is tied with the gateway. Gateway scripts alarms etc.

The specified service logon user account gives the Ignition Gateway permissions on your local computer to do things. Like access files in a directory, access the network etc... It doesn't have any bearing on permissions for users inside Ignition.

When you access files located across the network, the local_system account doesn't have access to those files, and IIRC doesn't have access to Windows network resources, printers etc... So you have to create a specific user in the domain, you are using a domain for this right?, that has access to those resources and have Ignition run using that account. That way, when Ignition attempts to connect to a network resource, they are authenticating as the user specified as the one that is running Ignition from the services.msc page. Ignition doesn't use the active user logged into Ignition to access the files, it uses the user that is specified to actually run the service to access resources across the network.


Ok I understand, the network resource and our server are on two different domains, will that be an issue? I was able to map the drive and work with it, so it wouldn't be right?

That's a better question for your IT group.
This isn't an Ignition issue per se, but more of a Windows configuration validation. If your IT group creates an account that can access the proper resources, and that account can log in to the PC where you have Ignition installed, it should just work.

It sounds like it should to be honest! Just to be sure, again, changing the local account to one that has access wont cause any downtime right? That is the last thing we want.

Well... you will have to shutdown the Ignition gateway to change the Logon Account.

As far as downtime, the only way to know for 100% sure is to setup a development gateway and try it there. None of us will be able to tell you for sure if you will have issues.

1 Like

I'm still waiting on the IT team, but here's something a little unconventional, perhaps crazy.

Bellow is a screenshot right. If I type this path: file:///L:/0/Current/, which is a directory in that shared folder that I am trying to access, is there a way to do this with ignitions system.perspective.navigate? I was messing around and I could not emulate it.

ignition perspective

That's the kind of thing that malware wants to do. Browsers only allow local file access via a user direct action.

1 Like

I figured, thanks!

Ok, I did something sort of CRAZY...
So I created a python script in the Ignitions pylib. If I use the python console to execute the script, it works perfectly for copying files from one place to another. Once the files are copied I'll use ignitions built in functions to download the copied file to the users PC, but this is yet to come as I am currently troubleshooting this error.

If I use ignition, I don't get any errors. The account has full access to where the python.exe is located, that same account is the one running on the service. No errors in the gateway either.

Here is my code:

	param1 = "//XX.XX.X.XXX/cad/CAD2/Drawings2/0/Current/0W390082-.GP4"
	param2 = "C://Drawings/Downloads/"
	result = system.util.execute(["C://Users/Administrator/AppData/Local/Programs/Python/Python310/python.exe", "C://Program Files/Inductive Automation/Ignition/user-lib/pylib/", param1, param2])
	if result ==0:
		system.perspective.print("It worked.")
		system.perspective.print("Did not work :(")

In an ignition perspective view: I am passing two parameters to the script, realistically I could limit it to one and be perfectly fine, and executing it. I get 0 errors on the gateway and in the project. - Well, I do get my "did not work :("

Where did you get the idea that system.util.execute returns a result? Why do you need to use external python to copy a file?