Talk:Users and groups
Username change tips
On 2nd though I'm unsure about the edit "Merging "change a user's login name" + Username change tips".
Now it should be correct, "Change a user's login name or home directory" is in one chapter, together with the infos + warning about the change on a actual user. Ua4000 (talk) 19:13, 23 June 2017 (UTC)
Unclear to me: Change a user's login name or home directory
This instructions from the page could be clearer:
To change a user's home directory:
# usermod -d /my/new/home -m username
-m option also automatically creates the new directory and moves the content there.
# ln -s /my/new/home/ /my/old/home
Make sure there is no trailing
Can we add an example? Say username is
archie and old home folder was
/mnt/sda3/home/archie. New home directory shall become
/home/archie. So, according to the instrcutions:
# usermod -d /home/archie archie
(Not using -m because files shall stay at
Then create a link from former home directory
/mnt/sda3/home/archie to the new one
# ln -s /home/archie/ /mnt/sda3/home/archie
However then there is a link in
archie that points to
/home/archie. Shouldn't it be the other way around? So when the system looks up
/home/archie instead it will go to
- The tip assumes that the
-mflag was used. This is indicated in the first sentence: "You can create a link from the user's former home directory to the new one." -- Lahwaacz (talk) 21:02, 26 October 2017 (UTC)
It is a good idea to add a column with the default gid to every group in the wiki table ? e.g. what is group 102 ?
# ls -la /usr/share/polkit-1 # drwxr-x--- 1 root 102 44 Dec 22 02:14 rules.d
Also I found in my cups directory files owned by 9xx. My first idea was to look in the wiki article...
- You can find those in DeveloperWiki:UID / GID Database. Also note that there were recently some changes towards dynamic allocation of the IDs , so the table may not be entirely correct. -- Lahwaacz (talk) 09:09, 24 December 2017 (UTC)
useradd primary / secondary group
I am noticing that the group created (with gid=uid) is empty by default in /etc/groups, is that expected or is it safer to also add manually the user in the group? Kewl (talk) 07:20, 20 May 2018 (UTC)
- The primary group is set in /etc/passwd, so it's fine that it appears empty in /etc/groups. Run
groupsto see all current groups. -- Lahwaacz (talk) 07:29, 20 May 2018 (UTC)
Utilities to handle the shadow file in acrh
Referring the template:accuracy in the users and groups#Other tools related to these databases section:
chage is just an example how one can modify the shadow file in arch. There are other utilties to modify other aspects of the shadow file. The versions of
vigr in arch has far less options compared to Debian, for example. On arch,
vipw -s exits with an error code of 1. Also compare to debian's man page. At the bottom of the later there is a reference to shadow-utils, as well as a link to passwd 1:4.5-1.1. shadow-utils is also mentioned for other distributions. Which is confusing. Can it be that shadow-utils has cease to exist at the upstream level, but continues to exist at the distributions level? Regid (talk) 17:01, 28 January 2019 (UTC)
- I'm not even sure how to parse any of this *or* the disputed section.
- is the only thing there is to discuss at all -- the upstream "shadow" project is mildly schizophrenic in that it calls itself "shadow" everywhere *except* the manpages which mention "shadow-utils". Debian packages the source package "shadow" as the split binary packages "login", passwd", and "uidmap" and does not package a binary package for either "shadow" or "shadow-utils" or anything else of the sort, while Fedora packages it as "shadow-utils". Arch Linux, Void Linux, Gentoo, OpenSUSE, Slackware, Solus, all have the "shadow" package.
- The bug report plainly states that vigr, vipw specifically from Eschwartz (talk) 21:25, 3 February 2019 (UTC) are considered deprecated in favor acquiring those programs from the shadow project instead. (Then it was rejected in favor of un-deprecating the util-linux versions due to the shadow project not being responsible developers.) --