Unable to launch MSI installers off NFS share
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:
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 ===
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.