Even if you solve your problem (probably network rights in the service account), you are setting yourself up for grief. When the target server reboots or is briefly unavailable, or is unavailable when Ignition starts, this breaks. Ignition won't reconnect without a (another) gateway restart.
Use UNC paths for all network resources. Run the gateway service with a domain account that has privileges to all the needed network resources. This is the only robust way to do this.
I am currently running this on my box and I have access to all of those resources but I cannot access those files. I can if I use the script console. I went through a bunch of posts on this on thought this was the way to go.
How do I define the account that runs the gateway service?
The gateway runs as a service. It is totally separate from whatever you do on the desktop on that box. Go to computer management, find services, find the Ignition service, and alter it to run with a suitably privileged account. (You might have to dig around--I avoid Windows like the plague, myself.)
Keep in mind that whatever you do in your own box will have to be set up similarly in a production environment. That might be much more trouble.
Consider not using an external network resource, but instead expose a network resource (named share) from the gateway. Then Ignition needs no dedicated user account for privileges, just read/write access to the folder you expose. Then you grant privileges as appropriate to the external consumers of the data.
No, I avoid the plague that is Windows. Others here can chime in if they please.
However, if you right-click on any arbitrary folder on a local disk in Windows, and open "Properties", one of the tabs available is "Sharing". Setting that up makes that folder reachable from other Windows machines just like mapping to any other file server.
On our drives we have network drives that are mapped and I was trying to map a folder on one of those drives. I tried to map the root drive that we map to our network drives and that worked.
Just so you know that it will break if the mapped drive is ever not available when Ignition starts. And if it ever becomes unavailable after Ignition is started, you have to restart Ignition to make it work again.
Just because IA documents this drive mapping option doesn't make it a good idea.
I have circled back to this and would like to get this working properly,
As a test,
I am logged into my dev box with an account that has access to the network drive in question and I starting the service with the same account.
If I use os.path.exists in the Script Console I get true. If I use os.path.exists in a view I get false.
Well, you've exhausted my experience with Windows. UNC paths work where I've done this, where the service user account's name and password were acceptable to the network share.
I don't think you will succeed until IT allows your network share to trust the gateway service's user (in a domain environment) or user/password (non-domain).
Let me repeat: I strongly recommend against using mapped drives. If you get mapped drives working with any credentials in the wrapper, you can use those credentials to run the service to make UNC paths work reliably.
I got nothing more for you. Get your IT group to fix this.