That releases the “smartscreen” block. My MSI had started and been through two forms.
That doesn’t mean anything. The block is a special “mark” (in a form of alternative file stream) of “untrusted” zone which was the source of the file. MSI installation works in two phases: impersonated (when msiexec is run under launching user’s account), and privileged (when it’s run from system account as a service). In the second phase (which is started after “two forms”) it checks different security settings, and might refuse to run what passed first stage. Hence my question.
Well, my MSI has no “Unblock” tickbox. I just tried to use it again from a folder without SYSTEM and it failed just the same, though this time asking for escalation after the desktop icon. BTW does “ebot” ever give up? (see above) Can you connect me to the MSI developers?
I was using it to modify this time, just remove a language.
Thank you for the effort to discover the possible source of the problem. Unfortunately, I wasn’t able to reproduce using a new virtual machine with a fresh Win 10 1803 installation. Downloads grant SYSTEM full access by default there. Maybe you’ve moved it somewhere?
Can you connect me to the MSI developers?
I am one of them (from your comment to ebot above, I take “MSI developers” as those who develop LibreOffice install package for Win, not MS developers creating the OS service).
Yes, I did mean excellent open-source developers like your good self! I have edited my self-solution to show that my problem is not widespread, at least I can’t yet identify what changed my folder permissions and it might be a rare security “fix”. I can only guess that perhaps the MSI could check for permissions it will need before getting so far?
BTW can you suggest documentation of what folder permissions and inheritances there ought to be in a standard Win10-1803 installation?
it might be a rare security “fix”
Might be. There are some tools for “hardening” this and that… and they might be useful actually, I don’t say they are all crap.
perhaps the MSI could check for permissions it will need before getting so far?
Well - we try to use as few non-standard MSI actions as possible. Such a check needs to be non-standard, and I’m sure that it would bring much more failures than avoided problems. Each non-standard action does 
- I say from experience.
Of course, I understand one’s frustration when stumbling across such a problem. But see: tens of millions of installs generate - let’s say - hundreds of error reports. That constitutes less than 0.01%. If we introduce a check without taking into account all possible situations, we will (1) need to support the additional code (man-work); and (2) deal with unforeseen consequences.
I assure you that resources like this (with questions+resolutions) deal with this much better.
When some reports start getting frequent, we see that a problem becomes more important. And we try to improve then.
can you suggest documentation of what folder permissions and inheritances there ought to be in a standard Win10-1803 installation?
No - I don’t know of such. But I can tell you which settings are on my test system if you need.
Brilliant response!
I have looked before for a good Win32 utility for mass permissions control (ACL) with not much success. There are very good apps for Linux using ntfs-3g and perl but of course they wouldn’t easily port to Windoze. I have a dual-boot system and several USB boots with different distributions so I can sort it. What would you use to just list yours, as you offered? (Don’t waste any more of your time - I’m retired!)
Brilliant response!
I have looked before for a good Win32 utility for mass permissions control (ACL) with not much success. There are very good apps for Linux using ntfs-3g and perl but of course they wouldn’t easily port to Windoze. I have a dual-boot system and several USB boots with different distributions so I can sort it. What would you use to just list yours, as you offered? (Don’t waste any more of your time - I’m retired!)
To list permissions, I’d use something like
get-childitem c:\users\user -recurse | where{$_.PsIsContainer} | get-acl | Out-Gridview
This isn’t suitable to apply - I have never looked a tool for that.
By the way: please mark your answer as correct one - this will signal others (looking for a similar problem) that the question has a solving answer.
Sorry to bother again but I can’t see any such option - perhaps because I answered it myself?
Thanks for the Powershell tip - works well.
Hi,
When installing LibreOffice 6.2.0 I’ve just got the same error: The system cannot open the device or file specified.
Follow the instructions ‘How to enable Windows Installer logging’. Put into Value data field all options: voicewarmupx.
Run the installer again.
After it fails, go into C:\Users\your_user_name\AppData\Local\Temp directory. Find in it the most recent .LOG file, something similar to MSI5093e.LOG.
The log will give you some clues about what and why the installer couldn’t open.
In my case I have C:\e directory mounted as E: drive. The installer or Windows 10, version 1809, I upgraded it on 2/17/2019, incorrectly interpreted E:\ path:
MSI (s) (D0:84) [23:11:07:693]: Error: Wrong Long Path Name:
E:\downloads\LibreOffice\LibreOffice_6.2.0_Win_x64.msi
MSI (s) (D0:84) [23:11:07:693]: Error: Wrong Path Name: \?\C:\e\downloads\LibreOffice\LibreOffice_6.2.0_Win_x64.msi
MSI (s) (D0:84) [23:11:07:693]: Error: This file path is updated, hence failing to create: E:\downloads\LibreOffice\LibreOffice_6.2.0_Win_x64.msi
MSI (s) (D0:84) [23:11:07:693]: Note: 1: 1309 2: 110 3: E:\downloads\LibreOffice\LibreOffice_6.2.0_Win_x64.msi
The system cannot open the device or file specified.
It is the first time after the Windows update I am installing LibreOffice. Something got changed. 
I’ve been installing LibreOffice from E: drive since version 4.0 without any problems.
This time I had to install it from C: drive.
PS. Don’t forget to remove Logging from Registry.
Just a hint: we have this FAQ, describing a logging method which does not require registry manipulations.
It is the first time after the Windows update I am installing LibreOffice. Something got changed.
This change must be something in Windows Installer: we didn’t change anything related in LibreOffice. The problem seems to be that deferred install phase (i.e., which runs as a system service, not as current logger-in user) cannot find a drive that is mounted for current user only, not system-wide. That it worked previously, only means that the installer was copied to some (temporary?) location prior to the deferred stage, which for some reason (internal to Windows Installer) doesn’t happen now - did MS broke own per-user mount point detection?
Uninstall KB4489899, than everyhting works fine again.
We have the same situation here with a simulated disk drive:
reg ADD “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\DOS Devices” /v “D:” /t REG_SZ /d “??\C:[whattever]”
I just spend some time by trying the solution with permission and **moving to C: ** drive and disabling the languages packs. On Win7 this doesn’t work. Other programs MSI setups work fine. but I find the solution (Hallelujah). Just convert the MSI to exe with some online utility and it will be fine. The security risk of course. These problems with MSI repeated from time to time. What is the benefit of making MSI installers anyway? That you can use it as auto updates?
I had the same issue updating to LibreOffice 6.2.7.1 on my Win10 (10.0.18362.356); the previous version updated fine, but I can’t remember which version of Win10 I had.
The following fix worked for me:
- click on the properties of the folder where the LibreOffice installer is installed (in my case, it was the “Downloads” folder)
- Allow “SYSTEM” full control of the folder
- Re-run the installation
As I mentioned above, this fixed the problem for me