Numeric group IDs for system groups
Wed May 23 20:05:00 GMT 2018
I am the community manager of X2Go, an open-source remote desktop and
remote application solution for Linux servers. While our server
component only runs on Linux, our client software is available for macOS
and Windows as well. The Windows version of X2GoClient relies on some
executables available through Cygwin.
On Windows 10, we are encountering the issue mentioned here in the FAQ:
Especially, we're getting hit by the fact that Microsoft has changed the
default group for %USERPROFILE% (and all files and directories created
in it) from "None" to <Username>.
This is why the second-to-last suggestion in that FAQ item doesn't help:
chgrp `id -g` ~/.ssh/*
will simply set the default group to the value it already has, and that
doesn't fix the issue.
The last suggestion in that FAQ item suggests using
chgrp None ~/.ssh/*
but also notes that the group name will vary depending on the operating
chgrp does work with numeric group identifiers, and it seems the "None"
group always gets the numeric id 197121 - so
chgrp 197121 ~/.ssh/*
would fix the issue regardless of the operating system language.
(In our case, it would be
chgrp 197121 %USERPROFILE%/.x2go/etc/ssh_host_key*
because it actually affects the host keys of an sshd running on the
Windows side, which we need for file sharing via sshfs, but you get the
Can anyone with authority on the issue confirm that 197121 always
corresponds to the "None" group (whatever it may be called due to the
language setting - in German, it is "Kein", for example)?
Or is this a faulty assumption and merely coincidence that we got that
result on the handful of machines we used for testing?
I'm seriously hoping this id is always the same, similar to the
well-known SIDs in Windows, but would really like a confirmation from
someone knowledgeable before we make the corresponding change in our
code and hose a large percentage of our users' systems once they deploy
In case it is of relevance, we are calling the executables (ssh-keygen,
sshd, and now chgrp and possibly setfacl as well) directly from a native
Windows application written in Qt and C++, not from a Cygwin bash window
or similar. In fact, there is no cygwin installation, it's just the
required executables and dlls residing in our own installation
directory. I can provide more detail or get you in contact with one of
our developers, if needed.
BAUR-ITCS UG (haftungsbeschrÃ¤nkt)
GeschÃ¤ftsfÃ¼hrer: Stefan Baur
EichenÃ¤ckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin