Run exe from network share, with/without admin privileges?

Question

I'm trying to run a Win7 exe that's on a network share (a Linux CIFS server). The share was created by a non-admin (see Windows 7 problem to access shared folder). I can read and edit and write files in the folder containing the exe. I can read (i.e., copy) the exe.

But when I try to run the exe, either by double-clicking and OK'ing the UAC dialog, or by right-clicking "Run as administrator", I get:

Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item.

Must I copy the exe to local disk before I can run it?

I followed the recipe at the (not yet accepted answer for) How can I run an EXE from a Network Share?, but that appears to grant only read permissions, not exe permissions.

(Distantly related: Cannot Run .exe from Network Drive.)

Solution 1

This is expected (although unusual) behaviour.

When you run a program from a network share, it can be done in a few ways.

1. The share is mapped to a network drive: for example g: -> \\server\share
2. 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.

Solution 2

You have to set the value EnableLinkedConnections to 1 as described in this KB article:

Mapped drives are not available from an elevated prompt when UAC is configured to "Prompt for credentials" in Windows
https://support.microsoft.com/en-us/kb/3035277

1. In Registry Editor, locate and then click the following registry subkey:

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

2. In the right pane, right-click New, and then click DWORD (32-bit) Value.

3. Name the new registry entry as EnableLinkedConnections.
4. Double-click the EnableLinkedConnections registry entry.
5. In the Edit DWORD Value dialog box, type 1 in the Value data field, and then click OK.
6. Exit Registry Editor, and then restart the computer.

Solution 3

Some installers need to be accessible by NT AUTHORITY\SYSTEM, but network drives are user-specific. EnableLinkedConnections won't help in this case.

Delete your existing network drive and map it again at system level. To do that, create a scheduled task with action: net.exe and arguments: use z: \\host\share\ (provide password, if needed) and change the account for running this task to NT AUTHORITY\SYSTEM. /PERSISTENT:yes does not seem to work, so you'll need to schedule it to run on boot

After you run it, whole system will see the network drive. In Windows explorer it will be displayed as disconnected, but it will work nevertheless.

Comments

[Camille Goudeseune]

At an admin-level command prompt, net use g: \\server\share succeeds: drive G appears and I can read and write in that folder. But when I run the exe from that prompt, I get Access is denied. The same happens with \\server\share\...\foo.exe.

[Camille Goudeseune]

After doing this, I still get Windows cannot access the specified.... (Even after spelling EnableLinkedConnections right and re-restarting!)

[LPChip]

Then the executable has different security settings than its folder.

[magicandre1981]

run process monitor in background while trying to run the exe.channel9.msdn.com/Shows/Defrag-Tools/…

[Camille Goudeseune]

Sure enough. On the Linux server, chmod a+x foo.exe made it executable from Windows.

[Camille Goudeseune]

I'm too lazy to undo this registry change, but I'll give it the benefit of the doubt, and guess that it helped solve the problem. +1. But I directly observed that LPChip's answer got the exe to work, so LPChip's answer gets accepted.

[Camille Goudeseune]

Some exes run fine, from command prompt and from Windows Explorer. Others run only for an instant and then return to the command prompt without any error. Maybe because they have console output. Anyways, just a comment, more investigation needed; the main question remains answered.

[Elliott B]

I was unable to set this special user using the gui, so I had to create task in cmd like schtasks /Create /RU "NT AUTHORITY\SYSTEM" /TR "net use z: \\192.168.1.1\share" /TN "map share" /SC ONLOGON. After reboot, the task says it completed successfully, but the result is (0x2) and the drive is not mapped.

[basin]

@ElliottB change the task to capture or redirect stdout and stderr and see what it prints

[basin]

@ElliottB you don't have to reboot, just run the task manually.