7

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 ===
wewantbananas
  • 71
  • 4
  • 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. – HopelessN00b Jan 29 '14 at 23:32
  • I thought this as well but I've copied the file locally and had it work successfully. I've also run into this issue with multiple MSI files on the share so it's pretty consistent with just that file type. – wewantbananas Jan 29 '14 at 23:33
  • 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.) – HopelessN00b Jan 29 '14 at 23:40
  • No luck, same error. I also tried copying it locally, marking it read only, and it still launches. It's odd. – wewantbananas Jan 29 '14 at 23:55
  • 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). – Evan Anderson Jan 30 '14 at 00: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"? – Katherine Villyard Jan 30 '14 at 00:25
  • 2
    msiexec also has options for verbose logging, which might help troubleshoot. – Greg Bray Jan 30 '14 at 04:30
  • Using msiexec throws the same error as well. Here is what I got from the verbose logging (copied the full log in the original post): MSI (c) (80:34) [10:12:29:246]: Note: 1: 2203 2: \\d-devfs02.eloquacorp.com\software\Nunit\NUnit-2.6.2.msi 3: -2147024846 MSI (c) (80:34) [10:12:29:247]: MainEngineThread is returning 1620 – wewantbananas Jan 30 '14 at 15:15
  • Try adding NFS server to the trusted Internet Zone, new Windows are very suspicious about from where they opens sensitive files i.e. exe, reg, msi, chm etc. – Nikolay Raspopov Sep 26 '15 at 11:37
  • We actually still have the same issue on Windows 10 Pro. – Kevin Lemaire Sep 09 '20 at 07:44

1 Answers1

2

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.

Bee Kay
  • 164
  • 7