I have a Linux server where I've configured a read only NFS share. The client I'm currently working on is a Windows Server 2008 R2 machine that has the NFS features installed. I'm able to open and execute all files except any MSI file. For some reason, unless I map the drive to a drive letter, I am unable to execute MSI installers over this share (the installer works when copied locally but I'm trying to avoid this if at all possible). I get the following error when I try to execute it straight off a UNC path:

This installation package could not be opened. Contact the application vendor to verify that this is a valid Windows Installer package.

What could be causing this? What is it about mapping the share that makes it work?

EDIT - Here are the results when call on the MSI using msiexec with verbose logging:

=== Verbose logging started: 1/30/2014  10:12:29  Build type: SHIP UNICODE 5.00.7601.00  Calling process: C:\Windows\system32\msiexec.exe ===
MSI (c) (80:F0) [10:12:29:228]: Font created.  Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg

MSI (c) (80:F0) [10:12:29:228]: Font created.  Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg

MSI (c) (80:34) [10:12:29:237]: Resetting cached policy values
MSI (c) (80:34) [10:12:29:237]: Machine policy value 'Debug' is 0
MSI (c) (80:34) [10:12:29:237]: ******* RunEngine:
           ******* Product: \\d-devfs02.domain.com\software\Nunit\NUnit-2.6.2.msi
           ******* Action: 
           ******* CommandLine: **********
MSI (c) (80:34) [10:12:29:246]: Note: 1: 2203 2: \\d-devfs02.domain.com\software\Nunit\NUnit-2.6.2.msi 3: -2147024846 
MSI (c) (80:34) [10:12:29:247]: MainEngineThread is returning 1620
=== Verbose logging stopped: 1/30/2014  10:12:29 ===
  • This error message is a common result of an installer that has been truncated or corrupted in transit, and as such, I would suggest that for some reason, Windows is able to read the start of the file from the NFS share, but not all of it. Jan 29, 2014 at 23:32
  • 3
    What happens if you temporarily set the NFS share to allow all permissions to any? (Looking to find out if the failure is a result of the MSI execution process trying to unpack the MSI temporarily to the NFS share, but not being able to because it's read-only.) Jan 29, 2014 at 23:40
  • 6
    I strongly suspect you're running into an edge case w/ the NFS client and Windows Installer (msiexec.exe). I can't imagine Microsoft did a lot of testing of deployment of packages from NFS volumes. I'm fuzzy on the specifics, but I know that adding the "mapped" "drive" causes your requests to run through some more "plumbing" (the Multiple Provider Router layer, I believe) before making it down to the NFS redirector. I haven't written anything that interfaces w/ Windows at that level, though, to say with certainty (hence this being a comment rather than an answer). Jan 30, 2014 at 0:06
  • 3
    Yeah, I think msiexec is getting confused about the path during the file extraction. Does it make a difference if you run it as "msiexec /i path\to\your.msi"? Jan 30, 2014 at 0:25
  • 2
    msiexec also has options for verbose logging, which might help troubleshoot.
    – Greg Bray
    Jan 30, 2014 at 4:30

1 Answer 1


Windows loves to write temporary files in the "working directory."

I suspect your scripting is doing a "cd" into that NFS directory and fails to write any temp files in that location, and dies in a pile, or users "click" on the icon within that NFS volume, and it fails in some way.

Revise your script to start in some r/w location, then call the explicit path to that NFS volume and file when attempting to execute it.

If the users are "clicking icons" to install with, then create a set of "shortcut" icons for people to run the installs from, and assign a "working directory" in each of the shortcuts. That should clear up most issues.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .