in your environment, UID and GID numbers can quickly
become inconsistent between servers. What this means
is that the “brian” user might have a UID of 404 on
Server1, a UID of 406 on Server2, and a UID of 402 on
This can be problematic for a couple of reasons. One of
the biggest reasons to standardize consistently UID and
GID numbers across all servers is so that you can move
to a central authentication system, such as LDAP. Central
authentication systems, like LDAP, generally require that
LDAP enabled users and groups have consistent UIDs
and GIDs across all servers that are LDAP connected.
Even if you are not looking to utilize central
authentication such as LDAP, you can still run in
to problems with having inconsistent UID and GID
numbers. For example, suppose you have a SAN LUN
mapped to ServerA. This LUN might have thousands of
files stored on it. Each file stored on the LUN has the
file owner and group stored as UID and GID numbers.
So if you take this LUN and unmap it from ServerA and
map it to ServerB, you will have issues if the UID and
GID numbers are not consistent between ServerA and
ServerB. In this scenario, you could have a couple of
problems. If user brian was UID 404 on ServerA, and user
bob is UID 404 on ServerB, after moving the LUN user
bob now owns all of user brian’s files. If there is no UID
404 on ServerB, then the file does not have an owner on
ServerB, and you simply see “404” as the owner when you
run a ls –al command.
You might also have issues with inconsistent UID/GID
numbers across servers when you are exporting NFS
shares between servers.
Steps to manually change a GID and UID
In this example, you will change a single UID for a user
(brian) and a GID for a group (testgroup). The “brian”
users original UID is 404, and the new UID will be 3504.
The “testgroup” groups original GID is 402, and the new
GID will be 5001. Changing a GID or UID number is a
Step 1. Stop applications and have users log off
Before changing GID or UID numbers, it is important to
stop all running applications and have all users log off
of the server. The process table keeps track of running
processes based on UID and GID numbers. So, if users
have running processes while these numbers are
changed, unpredictable results occur. Also, until the file
ownership is fixed in a later step, the users temporarily
loses access to their files.
Step 2. Find users who have the group as their primary
Each user on the system has a primary group defined in
the /etc/passwd file. When you change the GID number
in Step 3, AIX prints a warning message that it does not
update the /etc/passwd file with the new GID. So before
you change the GID, you first want to get a listing of
all users that have the group you are changing as their
primary group. There might not be any users with this as
their primary group, or there might be multiple users. To
find out, run the command in Listing 3 below:
Listing 3. lsuser output
lsuser -a pgrp ALL | grep
This command shows that there is one user (brian) on
the system with testgroup as their primary group. Make a
note of the users that this command displays as you will
need to run a command to fix them in a later step.
Step 3. Change the GID number
Use the chgroup command to change the GID of
testgroup to 5001 (originally it was GID 402).
Listing 4. chgroup output
chgroup id=5001 testgroup
3004-719 Warning: /usr/bin/chgroup does
not update /etc/passwd with the new gid.
The chgroup prints a warning message letting you know
that it does not update the /etc/passwd with the new
GID. This warning applies to any users that have this
group as their primary group. You collected a list of these
users in Step 2, and in the next step you will fix this.
Step 4. Fix users primary group
For each user that you noted in Step 2, run the following
command to fix their primary group. Note that there
might not be any users with the group as their primary
group, or there might be multiple users.
Listing 5. chuser command to update
chuser pgrp=testgroup brian
This chuser command updates the /etc/passwd file for
the brian user with the testgroup’s new GID number.