8

I am trying to run an executable file from a network drive on Windows 7 Professional (64-bit) in order to install a program, but, each time I try, it doesn't run and the following message appears:

{path-name}
The specified path does not exist.
Check the path, and then try again.

I am definitely connected to the network drive as I can see all of the directories and files, and can even open non-executable file types. Also, I am fairly confident that this is neither a firewall nor a permissions issue.

Improve this question
1
  • Some new information that I have just discovered: if I access the server through the 'Run' program, then the EXE works as it should. It is just accessing the server through the 'Network Location' section under 'Computer' in Windows Explorer that causes the issue.
    – user3509923
    May 19, 2014 at 13:36

9 Answers 9

Reset to default
10

If the server is running Samba, then you may need to add this option to the [global] section of smb.conf:

acl allow execute always = True

Source: Execute a .exe on a samba share - unix.stackexchange

This will tell Windows that all the files can be executed and beats running chmod a+x * for all files in the share, which also works.

Improve this answer
3
  • Thanks a lot, this has been bugging me for almost 6 months and somehow I only found your answer today!
    – OBones
    Mar 16, 2020 at 21:10
  • Thank you, that solved the problem! Another interesting symptom was that, from a command prompt, I would get "Access is denied." when trying to open a data file (.png, .jpg, etc.) with its default handler, by just typing the name of the data file. Even though the associated program file was on my C: drive, Windows would report "Access is denied."
    – Dave Burton
    May 4, 2020 at 19:36
  • Oh my goodness yes. In my case I just needed one EXE to be executable so using chmod was alright, but yes I see how this conf will generally help.
    – Spencer Williams
    Mar 23 at 17:16
7

It seems unlikely the OP is ever going to return, so I’ll address two specific cases that could have caused this:

When you have to enter credentials to access the network resource or if you are operating on a mapped drive, elevating a process may fail because of UAC.

This is because with UAC you are actually logged in with two sessions, one with administrative access and one without. These sessions are mostly separate, they don’t share mapped drives or network login tokens.

Your non-admin session has its mapped drives and any network login tokens. After confirming the UAC dialog, Windows tries to load the program in the admin session. It doesn’t have any network login tokens nor the mapped drives. As such, it will fail with either “file not found” or “access denied”.

Microsoft describes this behavior in greater detail in this article on TechNet.

Luckily, there is a workaround, enabling “Linked Connections” (described in the article mentioned above). The following .reg file will accomplish this:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"EnableLinkedConnections"=dword:00000001
Improve this answer
2

You might check with the developer to see if the executable you are launching is just a wrapper for one or more secondary executable's, which also have a particular path requirement.

You may need a specific drive letter mapped (eg you are launching from G: but the wrapped executable expects an H:), or to be authenticated to a different machine, or just a missing component.

Tools you can use:

  1. Dependency Walker This tool will tell you if your executable cannot find some component.
  2. Strings.exe. Run it against your executable. This tool will give you ascii characters that are human readable. Up to you to decide if they are relevant.
  3. A conversation with the developer or system integrator may go a long way to solve the missing path issue.
Improve this answer
2

There are a large number of reasons you could see that:

I would start with disabling UAC and check if this solves the problem. Then you know it is a permission issue and will "only" need to fix the specific issue there.

I do not remember if you can have Windows network drives mounted without the option to execute files as well.

Additionally checking the same file with another computer would be helpful as well, (Virtual one with another Windows OS f.e.)

For more in-depth steps:

Quote from Microsoft support:

This issue can occur if any of the following scenarios exist on your PC.

  • You do not have permissions to the file or the file location.
  • The file is on a location that is not currently accessible like a network location or an external drive that is not currently connected to the PC.
  • The file has been moved or deleted.
  • The file or shortcut is corrupt.
  • The file may be blocked by Windows.
  • Your antivirus software may be blocking the file.
Improve this answer
2
  • Thank you for your answer. I have just tried running an EXE from a different computer that is set up in exactly the same way as this one, and that runs it normally. Does this fact not rule out most, if not all, of the possibilities that you highlighted in your answer which could be causing the issue?
    – user3509923
    May 19, 2014 at 13:28
  • @user3509923 if the systems are completely (patches, registry, user account settings) the same i would go and check the logs on the other end (the network file system). I stress this exact part because there is often a small change, like a patch or a custom edit done for something else which might got forgotton. As for the actual network drive: Depending on your setup one of those PCs might have different permissions on the server itself, though my experience with WIN Server Network attached is too limited to be of help there.
    – Dennis Nolte
    May 19, 2014 at 14:24
1

When I ran into this it was because the share didn't have permissions set correctly. Try allowing "Domain Users" and "Domain Computers" access to the share.

Improve this answer
0

Ive seen this many times.

Not sure what causes it but if you copy the file to your local hard drive then run the EXE, it should work.

Improve this answer
2
  • Thank you for your answer. I know that that works. However, I'd like to know why this is happening as I have run EXEs plenty of times from network drives but never encountered this problem before. It seems a strange. Are you telling me that it is nothing to worry about?
    – user3509923
    May 19, 2014 at 13:14
  • Some filesystem operations are simply not supported on (network) file systems such as CIFS/SMB. Transactional NTFS is one.
    – HBruijn
    May 19, 2014 at 13:20
0

Some (especially older) exe's cannot run directly from a network share, but they can run from a network share if you mount the share with a drive letter.

Improve this answer
0

I was able to resolve this issue by deleting the computer object from the domain, recreating it, and re-joining the computer. It now runs the executable directly from the share drive without issue.

Shared vs NTFS permissions NTFS has inheritance Shares do not. That's why exe worked from subfolder and not parent folder share Share permissions were corrupt for this computer. Unjoining and rejoining computer to network fixed the share issue.

Improve this answer
-2

I have found the answer. It was in the control panel --> Internet options --> security tab.

  • This type of thing is related in this spot to configure as I remember.

  • I'm not sure which option it was exactly. It seems it is related to: opening a download and being prompted to "run" because it was downloaded.

  • I set all security to the lowest level on both computers. On the Vista/7 computer I customized to a even lower level. Maybe just using the slider switch is enough. I also switched off all windows firewalls. I don't think this all will turn out needed if looking at it closer.

  • BTW earlier I had to find out that windows Vista needs a right click and tick some end block option to be able to start a download. It was the same as with this.

Improve this answer

You must log in to answer this question.