Numeric group IDs for system groups

Stefan Baur
Wed May 23 20:05:00 GMT 2018

Hi List,

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
system language.

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
the update.

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.

Kind Regards,
Stefan Baur

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:
Unsubscribe info:

More information about the Cygwin mailing list