Score:2

How can I add an existing user to an existing group id (not group name)?

cn flag

I want to add an existing user, foo, to an existing group, docker. The issue is that my machine has two groups with the same name docker, one with id 131 and the other 999. I want to add foo into the docker 999 group. The following command only adds foo into the 131 docker group:

sudo usermod -aG docker foo

How can I add to the docker group with id 999 instead?

Update: after a further look, I realise that only the docker 131 group is listed under /etc/group:

$ cat /etc/group | grep docker
docker:x:131:Steve,Mark,Emmy,user1,foo

I have no idea where the 999 docker comes from, but the following user can run docker without sudo:

$ id user1
uid=260800(user1) gid=5000(student) groups=5001(sudoaccess),999(docker),27(sudo),124(sambashare),13010(eestaff),131(docker)

while the foo user cannot:

$ id foo
uid=305800(foo) gid=5000(student) groups=27(sudo),131(docker)
sudodus avatar
jp flag
1. How come you have two groups with the same group name? 2. You can try by making a backup copy of the file `/etc/group`, and then edit (with sudo access) it to add the user to the desired group (after the last colon, or if there is already some user there, write a comma and then add the user.. You should see the pattern in lines for some other groups.
Tu Bui avatar
cn flag
@sudodus weirdly ```/etc/group``` only has docker 131 group (question updated).
sudodus avatar
jp flag
How do you know that you have a user with the numeric id 999? That numeric id is used for the default user in live systems. And how did you get that number selected for a user id? Have you installed some special program package? Which version of Ubuntu are you running (20.04 LTS or some other version)? And is it a live system or an installed system?
sudodus avatar
jp flag
Maybe 999 was put into that list only in order to make it work for the default user in live systems. What is the output of `grep 131 /etc/group`; Please edit your original question and render the output as `code`
sudodus avatar
jp flag
I see your edits. Does it work now (or after logout/login or reboot) to use docker with the new user 'foo'?
sudodus avatar
jp flag
I see in a comment that you are running 16.04, released April 2016, end of support April 2021, so it is actually time to switch to a supported version.
Score:4
hr flag

So this turns out to be an XY problem

  1. problem as stated (X) "How to add existing user to existing group id (not group name)?"

  2. actual problem (Y) "What should I do if the /etc/group and /etc/gshadow files disagree about a group's numeric GID?"


X. How to add existing user to existing group id (not group name)?

It's not explicit in the man page, but usermod will accept a numeric GID as an argument for both the -g (primary group) and -G (secondary groups) options, at least as tested on Ubuntu 18.04.

Ex. given

$ groups testuser
testuser : testuser staff

$ getent group ftp
ftp:x:134:

then

$ sudo usermod -aG 134 testuser

$ groups testuser
testuser : testuser staff ftp

Y. What should I do if the /etc/group and /etc/gshadow files disagree about a group's numeric GID?

There's a command-line tool for that, provided as part of the passwd package:

NAME
       grpck - verify integrity of group files

SYNOPSIS
       grpck [options] [group [ shadow ]]

DESCRIPTION
       The grpck command verifies the integrity of the groups information. It
       checks that all entries in /etc/group and /etc/gshadow have the proper
       format and contain valid data. The user is prompted to delete entries
       that are improperly formatted or which have other uncorrectable errors.

       Checks are made to verify that each entry has:

       ·   the correct number of fields

       ·   a unique and valid group name

       ·   a valid group identifier (/etc/group only)

       ·   a valid list of members and administrators

       ·   a corresponding entry in the /etc/gshadow file (respectively
           /etc/group for the gshadow checks)

To check for inconsistencies, first run in read-only mode:

sudo grpck -r

(elevated privileges are required even here because /etc/gshadow is only readable by root). Then once you have identified the problem, run again interactively to correct problems:

sudo grpck

There is analogous utility pwck for ensuring consistency between /etc/passwd and /etc/shadow.

Tu Bui avatar
cn flag
Unfortunately it doesn't work in my case (Ubuntu 16.04). I think it has something to do with ```999``` docker not in ```/etc/group```. I have updated the question with more info.
hr flag
@TuBui It's possible that the GID for group docker is inconsistent between `/etc/group` and `/etc/gshadow` - please run `sudo pwck -r` and add the output to your question
hr flag
sorry I meant `sudo grpck -r` of course
Score:1
cn flag

TL;DR to answer the title question, please follow @steeldriver post aka. usermod works with group ID as well. The solution below is specifically for the problem described in the body of the OP.

Apparently the problem is resolved by editing /etc/group and change the docker group id 131 to 999. After logging out and in again I only have one group of docker left - the 999 group.

$ id foo
uid=305800(foo) gid=5000(student) groups=27(sudo),999(docker)

I very much hope changing /etc/group will not lead to any weird behaviour. The root of the problem is still unknown (the server login is also managed under a LDAP system so perhaps the two interferes each other).

hr flag
In future, I'd recommend using `grpck` to do this for you, rather than manually editing the file(s) directly
sudodus avatar
jp flag
+1 for steeldriver's comment and your own fear: changing the group id number of 'docker` to 999 might cause some weird behaviour. - Anyway, you can always reset `/etc/group`, if necessary for some other application, so good luck :-)
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.