Linux: Changing UIDs and GIDs for a user | Comments (5)
Posted in Code, Linux/Unix on 24th September 2008, 12:41 am by Stuart
Just had to do a quick switch over of UID and GIDs for a couple of users.
I’m using Puppet to manage server configurations and it’s got some nice features for automating the set-up of users. Unfortunately when I initially set-up the puppet directives, I overlooked setting the UID for each user which means that the UIDs assigned have been randomly created. As I want to maintain UIDs across all the boxes I’m using, it means there’s a need to migrate users’s uid’s and gids that are different.
WARNING: Messing with UIDs and GIDs can be hazardous to your sanity if it all goes pear-shaped. Using any of the scripts that follow is done entirely at your own risk.
A bunch of commands to change UIDS and GIDS
Here’s the commands to run as root to change the UID and GID for a user. Simply change the variables in angled brackets to match your settings:
usermod -u <NEWUID> <LOGIN>
groupmod -g <NEWGID> <GROUP>
find / -user <OLDUID> -exec chown -h <NEWUID> {} \;
find / -group <OLDGID> -exec chgrp -h <NEWGID> {} \;
usermod -g <NEWGID> <LOGIN>usermod and groupmod simply change the UID and GID for their respective named counterpart usermod also changes the UID for the files in the homedir but naturally we can’t assume the only place files have been created is in the user’s homedir.
The find command recurses the filesystem from / and changes everything with uid of OLDUID to be owned by NEWUID and them changes the group for the files owned by the OLDGROUP
The final usermod command changes the login group for the user
As Jared pointed out in the comments it’s a good idea to specify -h for the chgrp and chown commands so that symlinks aren’t followed. If anything that the symlink linked to is still owned by one of the users affected this will be sorted with the find commands anyway.
Swapping Users UIDs
In my case user bar had a UID of 1001 and user foo had a UID of 1002 and I wanted to swap them over. To do that you have to run the changes with an intermediate step or everything will get in a right pickle. So much so it would be the point in the film where the “real you” enters the room and tries to strangle you.
- Change foo’s UID and GID from 1001 -> 1012
- Change bar’s UID and GID from 1002 -> 1011
- Change foo’s UID and GID from 1012 -> 1002
- Change bar’s UID and GID from 1011 -> 1001
These steps assume that 1012 and 1011 are not taken naturally.
There you have it. User foo now has a UID of 1002 and the foo group now has a GID of 1002 and user bar has a UID of 1001 and the group bar’s GID is now 1001 too. Phew!
But, note that chown and chgrp follow symbolic links, altering the file pointed to rather than the link itself, unless you used the -h switch. If a user creates a link to a system file, they get ownership of it when you run your commands. You may not have known if this had happened unless you also used the -v switch to report all operations or ran find again after making the changes.
@Jared: Very good point well made. I’ve updated the post to reflect the need to use -h.
[...] users on all machines. Changing the ownership of those files is done according to this web page: http://muffinresearch.co.uk/archives…gids-for-user/ Note that this is most easily done with a script which is set up once based on the UIDs and GIDs [...]
Thanks, this helps greatly for me with a mixed environment of Macs and Linux installs. Where the UID and GID don’t match for the initial users in Fedora and Ubuntu and Mac OS, then after that I LDAP everything and change accordingly.
Laters…
I observed that the setuid, setgid and sticky bits are not retained after chown and chgrp commands are run. I had to track down the special files and reset these bits.
My advice is to list them before making the above changes. Here’s a command that I used to create my list: