Window 10 authorization problems

Window 10 authorization problems

[Robert McBroom]

Troubles through several cygwin releases with getting the files to have 
the right permissions when running startwinx from an initial cygwin64 
terminal. Messages follow:

xauth:  /home/mukx/.serverauth.7284 not writable, changes will be ignored
xauth:  /home/mukx/.Xauthority not writable, changes will be ignored
xauth:  timeout in locking authority file /home/mukx/.Xauthority

winInitMultiWindowWM - DISPLAY=:0.0
winMultiWindowXMsgProc - DISPLAY=:0.0
winMultiWindowXMsgProc - Could not open display, try: 1, sleeping: 5
winInitMultiWindowWM - Could not open display, try: 1, sleeping: 5

waiting for X server to begin accepting connections .
..
winMultiWindowXMsgProc - Could not open display, try: 2, sleeping: 5
winInitMultiWindowWM - Could not open display, try: 2, sleeping: 5

and so on until the system gives up.

A directory listing gives:

   ----------  2 mukx          mukx             0 Jan 18 18:44 
.serverauth.7284-c
   ----------  2 mukx          mukx             0 Jan 18 18:44 
.serverauth.7284-l
   ----------  1 mukx          mukx            54 Jan 18 18:44 .Xauthority
   ----------  2 mukx          mukx             0 Jan 18 18:44 .Xauthority-c
   ----------  2 mukx          mukx             0 Jan 18 18:44 .Xauthority-l

On Window 7 these files are properly read,write for the user.

Robert


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Window 10 authorization problems

[Brian Inglis]

On 2018-01-20 16:35, Robert McBroom wrote:
> Troubles through several cygwin releases with getting the files to have the
> right permissions when running startwinx from an initial cygwin64 terminal.
> Messages follow:
> xauth:  /home/mukx/.serverauth.7284 not writable, changes will be ignored
> xauth:  /home/mukx/.Xauthority not writable, changes will be ignored
> xauth:  timeout in locking authority file /home/mukx/.Xauthority
> winInitMultiWindowWM - DISPLAY=:0.0
> winMultiWindowXMsgProc - DISPLAY=:0.0
> winMultiWindowXMsgProc - Could not open display, try: 1, sleeping: 5
> winInitMultiWindowWM - Could not open display, try: 1, sleeping: 5
> waiting for X server to begin accepting connections .
> winMultiWindowXMsgProc - Could not open display, try: 2, sleeping: 5
> winInitMultiWindowWM - Could not open display, try: 2, sleeping: 5
> and so on until the system gives up.
> A directory listing gives:
>   ----------  2 mukx          mukx             0 Jan 18 18:44 .serverauth.7284-c
>   ----------  2 mukx          mukx             0 Jan 18 18:44 .serverauth.7284-l
>   ----------  1 mukx          mukx            54 Jan 18 18:44 .Xauthority
>   ----------  2 mukx          mukx             0 Jan 18 18:44 .Xauthority-c
>   ----------  2 mukx          mukx             0 Jan 18 18:44 .Xauthority-l
> On Window 7 these files are properly read,write for the user.

Normally a problem with no default ACls (DACLs) on the directory; use getfacl
and icacls to view, and setfacl to set up permissions like:

# file: /home/$USER
# owner: SYSTEM
# group: SYSTEM
user::rwx
user:$USER:rwx
group::---
group:Administrators:rwx
mask:rwx
other:---
default:user::rwx
default:user:$USER:rwx
default:group::---
default:group:Administrators:rwx
default:mask:rwx
default:other:---

C:/Users/$USER NT AUTHORITY\SYSTEM:(OI)(CI)(F)
             BUILTIN\Administrators:(OI)(CI)(F)
             $HOST\$USER:(OI)(CI)(F)

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Window 10 authorization problems

[Achim Gratz]

Robert McBroom writes:
> Troubles through several cygwin releases with getting the files to
> have the right permissions when running startwinx from an initial
> cygwin64 terminal. Messages follow:

Is that a network share?

> A directory listing gives:
>
>  ---------- 2 mukx mukx 0 Jan 18 18:44 .serverauth.7284-c
>
> On Window 7 these files are properly read,write for the user.

As Brian said, please check the DACL on your home directory via icacls.
The above shows that Cygwin thinks there are _no_ ACL attached and it
seems it can't create them either, so I suspect your home is on one of
those shares that disallow both the reading and writing of DACL.  You
could try to use it by mounting it with the "noacl" option, but that
will create other problems down the road, so you might need to move your
home directory (as far as Cygwin is concerned) someplace else.  This
might be as easy as using a subdirectory in your current home or it
might require using a different share.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Window 10 authorization problems

[Robert McBroom]

On 01/20/2018 08:39 PM, Brian Inglis wrote:
> On 2018-01-20 16:35, Robert McBroom wrote:
>> Troubles through several cygwin releases with getting the files to have the
>> right permissions when running startwinx from an initial cygwin64 terminal.
>> Messages follow:
>> xauth:� /home/mukx/.serverauth.7284 not writable, changes will be ignored
>> xauth:� /home/mukx/.Xauthority not writable, changes will be ignored
>> xauth:� timeout in locking authority file /home/mukx/.Xauthority
>> winInitMultiWindowWM - DISPLAY=:0.0
>> winMultiWindowXMsgProc - DISPLAY=:0.0
>> winMultiWindowXMsgProc - Could not open display, try: 1, sleeping: 5
>> winInitMultiWindowWM - Could not open display, try: 1, sleeping: 5
>> waiting for X server to begin accepting connections .
>> winMultiWindowXMsgProc - Could not open display, try: 2, sleeping: 5
>> winInitMultiWindowWM - Could not open display, try: 2, sleeping: 5
>> and so on until the system gives up.
>> A directory listing gives:
>>  � ----------� 2 mukx��������� mukx������������ 0 Jan 18 18:44 .serverauth.7284-c
>>  � ----------� 2 mukx��������� mukx������������ 0 Jan 18 18:44 .serverauth.7284-l
>>  � ----------� 1 mukx��������� mukx����������� 54 Jan 18 18:44 .Xauthority
>>  � ----------� 2 mukx��������� mukx������������ 0 Jan 18 18:44 .Xauthority-c
>>  � ----------� 2 mukx��������� mukx������������ 0 Jan 18 18:44 .Xauthority-l
>> On Window 7 these files are properly read,write for the user.
> Normally a problem with no default ACls (DACLs) on the directory; use getfacl
> and icacls to view, and setfacl to set up permissions like:
>
> # file: /home/$USER
> # owner: SYSTEM
> # group: SYSTEM
> user::rwx
> user:$USER:rwx
> group::---
> group:Administrators:rwx
> mask:rwx
> other:---
> default:user::rwx
> default:user:$USER:rwx
> default:group::---
> default:group:Administrators:rwx
> default:mask:rwx
> default:other:---
>
> C:/Users/$USER NT AUTHORITY\SYSTEM:(OI)(CI)(F)
>               BUILTIN\Administrators:(OI)(CI)(F)
>               $HOST\$USER:(OI)(CI)(F)
>
Thanks Brian.� Made some progress.

$ getfacl /home/$USER
# file: /home/mukx
# owner: mukx
# group: mukx
user::rwx
group::rwx
other:rwx
default:user::---
default:group::---
default:other:rwx

The default DACL's look strange with other enabled.� Looked at the root

$ getfacl /
# file: /
# owner: Administrators
# group: Administrators
user::rwx
group::rwx
other:rwx
default:user::---
default:group::---
default:other:rwx

Used setacl

$ getfacl /home/mukx
# file: /home/mukx
# owner: mukx
# group: mukx
user::rwx
group::rwx
other:rwx
default:user::rwx
default:group::rwx
default:other:rwx

startxwin will now run when the initial cygwin64 terminal is started 
with "run as administrator" but not otherwise from the same windows user 
who is the system administrator.

 �-rw-------� 1 mukx mukx����������� 54 Jan 21 13:37 .serverauth.5628
 �-rw-------� 1 mukx��������� mukx���������� 286 Jan 21 13:37 .Xauthority
 �-rw-------� 1 mukx��������� mukx���������� 764 Jan 21 13:38 
.xsession-errors



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Window 10 authorization problems

[Robert McBroom]

On 01/21/2018 03:28 AM, Achim Gratz wrote:
> Robert McBroom writes:
>> Troubles through several cygwin releases with getting the files to
>> have the right permissions when running startwinx from an initial
>> cygwin64 terminal. Messages follow:
> Is that a network share?
Data drive

D:\cygwin64\
>> A directory listing gives:
>>
>>   ---------- 2 mukx mukx 0 Jan 18 18:44 .serverauth.7284-c
>>
>> On Window 7 these files are properly read,write for the user.
> As Brian said, please check the DACL on your home directory via icacls.
> The above shows that Cygwin thinks there are _no_ ACL attached and it
> seems it can't create them either, so I suspect your home is on one of
> those shares that disallow both the reading and writing of DACL.  You
> could try to use it by mounting it with the "noacl" option, but that
> will create other problems down the road, so you might need to move your
> home directory (as far as Cygwin is concerned) someplace else.  This
> might be as easy as using a subdirectory in your current home or it
> might require using a different share.
>
>
> Regards,
> Achim.

Both Windows 10 home and the insider edition of Windows 10 Pro are 
installed and share the data drive.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Window 10 authorization problems

[Achim Gratz]

Robert McBroom writes:
> Data drive
>
> D:\cygwin64\

But that's not where your home directory is?

> Both Windows 10 home and the insider edition of Windows 10 Pro are
> installed and share the data drive.

If you share the home directory between two installations, then you
might see interesting problems unless both machines are joined to the
same domain.

But I really think from your other posting that the default DACL on your
home directory are sabotaging Cygwin's attempt at providing POSIX
semantics, so you should have better luck separating the Windows home
directory from your Cygwin one, then removing any inherited DACL from
the Cygwin home directory (don't do this to your Windows home
directory).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Window 10 authorization problems

[Brian Inglis]

On 2018-01-24 22:22, Robert McBroom wrote:
> On 01/20/2018 08:39 PM, Brian Inglis wrote:
>> On 2018-01-20 16:35, Robert McBroom wrote:
>>> Troubles through several cygwin releases with getting the files to have the
>>> right permissions when running startwinx from an initial cygwin64 terminal.
>>> Messages follow:
>>> xauth:� /home/mukx/.serverauth.7284 not writable, changes will be ignored
>>> xauth:� /home/mukx/.Xauthority not writable, changes will be ignored
>>> xauth:� timeout in locking authority file /home/mukx/.Xauthority
>>> winInitMultiWindowWM - DISPLAY=:0.0
>>> winMultiWindowXMsgProc - DISPLAY=:0.0
>>> winMultiWindowXMsgProc - Could not open display, try: 1, sleeping: 5
>>> winInitMultiWindowWM - Could not open display, try: 1, sleeping: 5
>>> waiting for X server to begin accepting connections .
>>> winMultiWindowXMsgProc - Could not open display, try: 2, sleeping: 5
>>> winInitMultiWindowWM - Could not open display, try: 2, sleeping: 5
>>> and so on until the system gives up.
>>> A directory listing gives:
>>> � ----------� 2 mukx��������� mukx������������ 0 Jan 18 18:44 .serverauth.7284-c
>>> � ----------� 2 mukx��������� mukx������������ 0 Jan 18 18:44 .serverauth.7284-l
>>> � ----------� 1 mukx��������� mukx����������� 54 Jan 18 18:44 .Xauthority
>>> � ----------� 2 mukx��������� mukx������������ 0 Jan 18 18:44 .Xauthority-c
>>> � ----------� 2 mukx��������� mukx������������ 0 Jan 18 18:44 .Xauthority-l

You mailer is not setting your charset properly - please fix for readability.

>>> On Window 7 these files are properly read,write for the user.
>> Normally a problem with no default ACls (DACLs) on the directory; use getfacl
>> and icacls to view, and setfacl to set up permissions like:
>>
>> # file: /home/$USER
>> # owner: SYSTEM
>> # group: SYSTEM
>> user::rwx
>> user:$USER:rwx
>> group::---
>> group:Administrators:rwx
>> mask:rwx
>> other:---
>> default:user::rwx
>> default:user:$USER:rwx
>> default:group::---
>> default:group:Administrators:rwx
>> default:mask:rwx
>> default:other:---
>>
>> C:/Users/$USER NT AUTHORITY\SYSTEM:(OI)(CI)(F)
>>              BUILTIN\Administrators:(OI)(CI)(F)
>>              $HOST\$USER:(OI)(CI)(F)
>>
> Thanks Brian.� Made some progress.
> 
> $ getfacl /home/$USER
> # file: /home/mukx
> # owner: mukx
> # group: mukx
> user::rwx
> group::rwx
> other:rwx
> default:user::---
> default:group::---
> default:other:rwx
> 
> The default DACL's look strange with other enabled.� Looked at the root
> 
> $ getfacl /
> # file: /
> # owner: Administrators
> # group: Administrators
> user::rwx
> group::rwx
> other:rwx
> default:user::---
> default:group::---
> default:other:rwx
> 
> Used setacl
> 
> $ getfacl /home/mukx
> # file: /home/mukx
> # owner: mukx
> # group: mukx
> user::rwx
> group::rwx
> other:rwx
> default:user::rwx
> default:group::rwx
> default:other:rwx

Would change that to:
...
 other:r-x
 default:user::rwx
 default:group::rwx
 default:other:r-x

Check icalcs shows similar permissions to getfacl, and use icacls or Windows
Explorer directory Properties/Security to fix permissions, then retry getfacl
and ls -l.
You may have to use Windows Explorer Security to propagate the DACL changes down
your tree.

> startxwin will now run when the initial cygwin64 terminal is started with "run
> as administrator" but not otherwise from the same windows user who is the system
> administrator.

Check your cygwin directory ACLs and DACLs, and apply similar changes as required.

My X start shortcut runs as me:
	C:\usr\local\cygwin64\bin\run.exe --quote /usr/bin/bash.exe -l -c "cd; exec
/usr/bin/startxwin"

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Window 10 authorization problems

[Robert McBroom]

On 01/25/2018 12:53 PM, Achim Gratz wrote:
> Robert McBroom writes:
>> Data drive
>>
>> D:\cygwin64\
> But that's not where your home directory is?
Next level down

D:\cygwin64\home

>
>> Both Windows 10 home and the insider edition of Windows 10 Pro are
>> installed and share the data drive.
> If you share the home directory between two installations, then you
> might see interesting problems unless both machines are joined to the
> same domain.
Same machine multiboot.
> But I really think from your other posting that the default DACL on your
> home directory are sabotaging Cygwin's attempt at providing POSIX
> semantics, so you should have better luck separating the Windows home
> directory from your Cygwin one, then removing any inherited DACL from
> the Cygwin home directory (don't do this to your Windows home
> directory).
>
>
> Regards,
> Achim.



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple