Hi there, in my /etc/login.defs it says
USERGROUPS_ENAB yes
However, when I do a
useradd -m username
the new user’s primary group is users (gid 985) instead of username (gid=uid).
Do I have reading difficulties when reading Users and groups - ArchWiki or useradd(8) - Linux manual page ?
It clearly says in this source that I can omit -U if USERGROUPS_ENAB is set to yes.
Me clueless.
That should be the case, yes.
Can we see
useradd -D
Hi Head_on_a_Stick, thx for offering your help…
$ useradd -D
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=
SKEL=/etc/skel
CREATE_MAIL_SPOOL=no
and
# cat /etc/default/useradd
# useradd defaults file for ArchLinux
# original changes by TomK
GROUP=users
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
CREATE_MAIL_SPOOL=no
well, I have read
man useradd
and I suspect that GROUP=users and/or GROUP=100 might be part of the problem. Probably Google is going to give me the answer soon.
Still I am wondering why this is the archlab’s default behaviour.
That’s the upstream default: https://git.archlinux.org/svntogit/packages.git/tree/trunk/useradd.defaults?h=packages/shadow
useradd -D from the ArchLabs ISO image shows
GROUP=985
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
CREATE_MAIL_SPOOL=no
And useradd -m foo results in user foo having GID=UID.
Have you changed anything else in /etc/login.defs?
grep -v '^#\|^$' /etc/login.defs
I haven’t changed a thing. I’m going to have a look into the archlabs-image which I used to install my system. I know that the shasums were correct and I very probably downloaded it with Transmission/Bittorrent, which in itself should garanty integrity of the image as long as one can trust the magnet-link on sourceforge.
# grep -v '^#\|^$' /etc/login.defs
FAIL_DELAY 3
LOG_UNKFAIL_ENAB no
LOG_OK_LOGINS no
SYSLOG_SU_ENAB yes
SYSLOG_SG_ENAB yes
CONSOLE /etc/securetty
SU_NAME su
MAIL_DIR /var/spool/mail
HUSHLOGIN_FILE .hushlogin
ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/bin
ENV_PATH PATH=/usr/local/sbin:/usr/local/bin:/usr/bin
TTYGROUP tty
TTYPERM 0600
ERASECHAR 0177
KILLCHAR 025
UMASK 077
PASS_MAX_DAYS 99999
PASS_MIN_DAYS 0
PASS_WARN_AGE 7
UID_MIN 1000
UID_MAX 60000
SYS_UID_MIN 500
SYS_UID_MAX 999
GID_MIN 1000
GID_MAX 60000
SYS_GID_MIN 500
SYS_GID_MAX 999
LOGIN_RETRIES 5
LOGIN_TIMEOUT 60
CHFN_RESTRICT rwh
DEFAULT_HOME yes
USERGROUPS_ENAB yes
MOTD_FILE
ENCRYPT_METHOD SHA512
# mount -o loop /home/shared/isos/archlabs-2019.01.20.iso /mnt/root
# mount -o loop /mnt/root/arch/x86_64/airootfs.sfs /mnt/tmp
# cd /mnt/tmp
and
# grep -v '^#\|^$' etc/login.defs
[..]
# cat etc/default/useradd
[..]
give my the same outputs as above. Now, interestingly enough, as USER
$ useradd -D
gives me
GROUP=100
but as ROOT
# useradd -D
gives me
GROUP=985
Which doesn’t explain why a
# useradd -m username
puts the new user into group into users (gid 985) despite
USERGROUPS_ENAB yes
The USERGROUPS_ENAB from the /etc/login.defs comment, does:
Enable setting of the umask group bits to be the same as owner bits (examples: 022 -> 002, 077 -> 007) for non-root users, if the uid is the same as gid, and username is the same as the primary group name.
This also enables userdel to remove user groups if no members exist.
The reason you’re getting the “users” group is in /etc/default/useradd I think
# useradd defaults file for ArchLinux
# original changes by TomK
GROUP=users <<<<<<<<<<<<<<<<< Here
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
CREATE_MAIL_SPOOL=no
Is there a new group created for you’re new user matching username, and have they been added to it?
It’s worth noting we don’t change any of this stuff, just using the Arch defaults for basically everything that doesn’t need to be changed for install (keyboard, time, locale, etc.).