* network installation failed, new diagnostics
@ 2017-01-15 22:49 Thomas Wolff
2017-01-16 13:00 ` Corinna Vinschen
2017-01-16 18:02 ` Achim Gratz
0 siblings, 2 replies; 4+ messages in thread
From: Thomas Wolff @ 2017-01-15 22:49 UTC (permalink / raw)
To: cygwin-apps
Concerning https://cygwin.com/ml/cygwin-apps/2016-07/msg00021.html,
I have some new insights; first, I tried with a range of older versions
of setup.exe (from the cygwin time machine) but all failed, so its not a
regression as I had speculated.
Then I tried to run setup.exe without elevation, by elevating before
(running mintty as adminstrator). So I noted (and could have checked
this earlier...) that the involved network mounts were not fully
established:
mount (unelevated):
L:/TGI/cygwin7 on / type ntfs (binary,auto)
L: on /cygdrive/l type ntfs (binary,posix=0,user,noumount,auto)
...
mount (elevated):
//141.64.144.100/Labormaterial/TGI/cygwin7 on / type ntfs (binary,auto)
...
After fixing the mount:
net use L: '\\141.64.144.100\Labormaterial'
setup.exe works as expected.
Not being familiar with details of Windows permission stuff and
user-specific mounts myself, does this help to analyse and maybe even
fix the situation?
Thanks
Thomas
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: network installation failed, new diagnostics
2017-01-15 22:49 network installation failed, new diagnostics Thomas Wolff
@ 2017-01-16 13:00 ` Corinna Vinschen
2017-01-21 19:28 ` Thomas Wolff
2017-01-16 18:02 ` Achim Gratz
1 sibling, 1 reply; 4+ messages in thread
From: Corinna Vinschen @ 2017-01-16 13:00 UTC (permalink / raw)
To: cygwin-apps
[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]
On Jan 15 23:49, Thomas Wolff wrote:
> Concerning https://cygwin.com/ml/cygwin-apps/2016-07/msg00021.html,
> I have some new insights; first, I tried with a range of older versions of
> setup.exe (from the cygwin time machine) but all failed, so its not a
> regression as I had speculated.
>
> Then I tried to run setup.exe without elevation, by elevating before
> (running mintty as adminstrator). So I noted (and could have checked this
> earlier...) that the involved network mounts were not fully established:
>
> mount (unelevated):
> L:/TGI/cygwin7 on / type ntfs (binary,auto)
> L: on /cygdrive/l type ntfs (binary,posix=0,user,noumount,auto)
> ...
>
> mount (elevated):
> //141.64.144.100/Labormaterial/TGI/cygwin7 on / type ntfs (binary,auto)
> ...
>
> After fixing the mount:
> net use L: '\\141.64.144.100\Labormaterial'
>
> setup.exe works as expected.
>
> Not being familiar with details of Windows permission stuff and
> user-specific mounts myself, does this help to analyse and maybe even fix
> the situation?
This is an UAC issue, not a Cygwin setup issue. When elevating, the
mounts are not propagated to the elevated processes. There's a
documented registry value enabling the supposedly dangerous propagation
of mount point to elevated processes, but I don't knowe it off the top
of my head. You may want to search MSDN.
HTH,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: network installation failed, new diagnostics
2017-01-15 22:49 network installation failed, new diagnostics Thomas Wolff
2017-01-16 13:00 ` Corinna Vinschen
@ 2017-01-16 18:02 ` Achim Gratz
1 sibling, 0 replies; 4+ messages in thread
From: Achim Gratz @ 2017-01-16 18:02 UTC (permalink / raw)
To: cygwin-apps
Thomas Wolff writes:
> Concerning https://cygwin.com/ml/cygwin-apps/2016-07/msg00021.html,
> I have some new insights; first, I tried with a range of older
> versions of setup.exe (from the cygwin time machine) but all failed,
> so its not a regression as I had speculated.
Your user mounts are not present in the elevated shell, thanks to how
UAC sets you up.
> After fixing the mount:
> net use L: '\\141.64.144.100\Labormaterial'
It*s usually easier to create a temporary drive letter by using
pushd \\someserver\somedir
which is for whatever reason the only way to change into a UNC path in
cmd.exe.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: network installation failed, new diagnostics
2017-01-16 13:00 ` Corinna Vinschen
@ 2017-01-21 19:28 ` Thomas Wolff
0 siblings, 0 replies; 4+ messages in thread
From: Thomas Wolff @ 2017-01-21 19:28 UTC (permalink / raw)
To: cygwin-apps
Am 16.01.2017 um 14:00 schrieb Corinna Vinschen:
> On Jan 15 23:49, Thomas Wolff wrote:
>> Concerning https://cygwin.com/ml/cygwin-apps/2016-07/msg00021.html,
>> I have some new insights; first, I tried with a range of older versions of
>> setup.exe (from the cygwin time machine) but all failed, so its not a
>> regression as I had speculated.
>>
>> Then I tried to run setup.exe without elevation, by elevating before
>> (running mintty as adminstrator). So I noted (and could have checked this
>> earlier...) that the involved network mounts were not fully established:
>>
>> mount (unelevated):
>> L:/TGI/cygwin7 on / type ntfs (binary,auto)
>> L: on /cygdrive/l type ntfs (binary,posix=0,user,noumount,auto)
>> ...
>>
>> mount (elevated):
>> //141.64.144.100/Labormaterial/TGI/cygwin7 on / type ntfs (binary,auto)
>> ...
>>
>> After fixing the mount:
>> net use L: '\\141.64.144.100\Labormaterial'
>>
>> setup.exe works as expected.
>>
>> Not being familiar with details of Windows permission stuff and
>> user-specific mounts myself, does this help to analyse and maybe even fix
>> the situation?
> This is an UAC issue, not a Cygwin setup issue. When elevating, the
> mounts are not propagated to the elevated processes. There's a
> documented registry value enabling the supposedly dangerous propagation
> of mount point to elevated processes, but I don't knowe it off the top
> of my head. You may want to search MSDN.
On my home systems, mounts are not propagated at all, I wouldn't expect
setup to work then, agreed.
However, on that lab systems, the mounts are kind of half-way propagated
to elevated mode.
They and visible and accessible using the network path (cd
//141.64.144.100/Labormaterial/TGI; ...).
Now setup.exe apparently has remembered the network path for the Local
Package Directory which appears as \\141... in the respective setup.exe
screen, and in fact it does all the downloading to that directory, it
just fails during later installation which corresponds to the Root
Directory path appearing in drive format (L:...) in the respective
setup.exe screen.
I'm just thinking if setup.exe would handle the Root Directory path in
the same way as it handles the Local Package Directory path, the setup
should work in that case.
------
Thomas
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-01-21 19:28 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-15 22:49 network installation failed, new diagnostics Thomas Wolff
2017-01-16 13:00 ` Corinna Vinschen
2017-01-21 19:28 ` Thomas Wolff
2017-01-16 18:02 ` Achim Gratz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).