This is expected (although unusual) behaviour.
When you run a program from a network share, it can be done in a few ways.
- The share is mapped to a network drive: for example
g:
-> \\server\share
- The share is accessed directly by the share:
\\server\share
The first one can already cause a problem when you run a program as Administrator and I'll explain this below.
What happens when I run a program as administrator?
When you run a program as administrator, a new environment is created and the profile for Administrator is loaded. Although it will use the rights your user has, it obviously has additional rights for the administrator user. As a concequence, any mapping to a network drive are not created, and thus your Administrator user does not have any additional network mappings present in its profile, thus the g: does not exists.
It is even possible if the security settings on the share are very tight, the administrator user does not have permission either.
How to troubleshoot and overcome the problem?
Obviously you can just copy the file locally and run it then, but lets assume you don't want to do this.
You can start a command prompt as administrator first. From there enter the following command:
net use g: \\server\share
Replace the drive and share so they match your existing share.
As long as this command prompt window is open, you can execute your executable as administrator and it will work guaranteed.
If your user does not have rights to the \\server\share
, net use will fail with an error telling you exactly this, so you know where this problem is.
If the rights are good, you can alternatively access the executable by going to \\server\share
and run the executable as administrator. This eliminates the requirement for having a network share first in a different environment.