[Perspective] Mapping a Network Drive

Ignition
, ,
1

Hello. I'm trying to map a network drive so that I'll be able to write a file in a custom folder. I've followed this guide and honestly I don't see any error message in my wrapper.log file.

This is my ignition.conf snippet:

#********************************************************************
# Wrapper Network Drive
#********************************************************************
wrapper.share.1.location=\\192.168.xxx.xxx\scada
wrapper.share.1.target=Z:
wrapper.share.1.type=DISK

Just to test if I've access to the mapped drive, I've written this simple Gateway script.

import os
import traceback

logger = system.util.getLogger("mapped-network-drive")

def write_json(file_name, dic, debug=False):
	try:
		path = "Z:/Export"
		logger.debug(path)
		file_list = os.listdir(path)
		logger.debug(file_list)
	except: logger.error("Error: %s" % traceback.format_exc())

Then I've triggered it via a Perspective button, but I only get this error into the Gateway logs:

Error: Traceback (most recent call last): File "<module:gdm.test>", line 22, in write_json OSError: [Errno 20] Not a directory: 'Z:/Export'

What am I missing? I've also tried to map this drive on the same system (a Windows one) where the Gateway is running and I have access to it.

2

The gateway runs as its own user and has its own environment. Drives mapped by a user logged into the gateway's desktop have no relation to the gateway's service environment. And, by default, the gateway runs as a system user that has no network privileges. Did you provide a user name and password in ignition.conf for the service to use to make that network connection?

Consider assigning a real user to the gateway's service (one that has network privileges) and then use UNC paths in your scripts.

Whatever you do won't take effect until you restart the gateway.

Let me emphasize: Mapping a drive on the gateway's desktop does NOTHING for the gateway's Ignition service.

3 Likes
3

I didn't provide any authentication data, so I suppose that's the issue, thank you: I thought the Ignition service would share the same environment of the logged in account which has the correct access privileges.
I'm afraid this will put me on a collision route with the IT guys, considering putting the network credentials as clear text inside of ignition.conf is not going to be appreciated. It would be nice to have some kind of encryption for the passwords written into this file, similarly to what Node-RED does with its credentials inside of settings.js (hashed using the bcrypt algorithm).

4

This is a common misconception. It isn't Ignition's doing--this is standard Windows behavior.

Which is why you should have the Ignition service run as a specific, credentialed, user. Then the password is placed in Window's registry instead of in clear text.

2 Likes
5

If I run Ignition service as a specific, credentialed user, I suppose those lines wouldn't be necessary inside of ignition.conf.

wrapper.ntservice.account=user
wrapper.ntservice.password=password
wrapper.share.1.account=domain\user
wrapper.share.1.password=password

That's because, as you said, those credentials (network user/password and Windows' account user/password) would be placed in Windows' registry, right?

Thank you for your help.

1 Like
6

These would be one and the same. And if you use UNC paths, you also avoid the problem that occurs when a particular server is down at the time Ignition restarts--a missing mapped drive in ignition.conf would stay missing until another Ignition restart.

2 Likes