Explore NY Stream

— LiveStream

When the same user account ends up with different numeric UIDs across your AIX servers, you need to correct and synchronize the UIDs in AIX by picking one canonical UID, applying it with chuser on every host, and re-owning the affected files with find and chown. This guide walks through diagnosing duplicate or mismatched UIDs, fixing them safely, and verifying the result so file ownership stays consistent across NFS, backups, and shared storage.

Why duplicate and mismatched UIDs happen in AIX

On a single AIX system, the operating system enforces a 1:1 mapping between a username and a numeric UID. The login name is only a label for humans; UNIX permissions, file ownership, and process credentials are all keyed off the numeric UID. Problems appear the moment you operate a fleet of servers that share files but do not share a central identity source.

In the real world, accounts are frequently provisioned by hand-rolled mkuser scripts, one per host. If each script hard-codes its own UID (or simply takes the next free number on that box), the same person can become UID 3412 on one server, 3980 on another, and 3988 on a third. Everything looks fine until files cross a boundary.

Common triggers for duplicate UIDs in AIX include:

Independent provisioning scripts that assign UIDs per host instead of from a shared registry.
NFS-mounted home directories or shared filesystems where ownership is resolved by number, not name — so files owned by 3412 on the NFS server show up as a different user on a client that maps 3412 to someone else.
Restores and migrations that carry over numeric ownership from an old box onto a new one with a different UID scheme.
Two real accounts colliding on one number, which is the dangerous case: person A and person B both end up as UID 3412 and can read and modify each other's data.

The symptom is almost always the same: ls -l shows a bare number instead of a name, or a user can suddenly see files they should not, or a batch job writes files that the "same" user cannot read on another node.

The plan: pick one canonical UID and synchronize it everywhere

The safe strategy to correct and synchronize UIDs in AIX has three phases. Do them in order and never skip the file re-ownership step — changing a user's UID does not retroactively change the ownership of files that user already created.

Discover every UID currently assigned to the account across all hosts and all provisioning scripts.
Decide on a single canonical UID (the standard convention is the lowest/earliest one) and apply it with chuser on each host.
Re-own the affected files from the old numeric UID to the username, then fix the source scripts so the drift never returns.

Throughout the examples below the account is dsunder (Dejan Sunderic) and the canonical UID is 3412, the lowest value seen across the fleet.

What you need before you start

Root access on every affected host (UID changes and re-ownership require it).
A maintenance window — the user should be logged out and their processes stopped, because changing a UID while processes own files as the old number leaves orphaned ownership.
A current backup of /etc/passwd, /etc/group, and /etc/security/passwd on each host, plus a recent filesystem backup.

Step 1 — Discover every UID assigned to the account

Start by auditing your account-creation scripts. If your team provisions users with per-host mkuser wrappers, every UID the account was ever given is recorded there. Grep the script directory for the login name:

Search the create-id scripts for the username:

grep -i dsunder /home/nsek/create_id_grp/*

A fleet with drift returns something like this — note the differing id= values for the same person:

Script / host	UID assigned	Primary group
createid-bvsnmdbua28	3412	fcirgrp
createid-dmcadmdv01corp	3412	edwetl
createid-dmcadmqa01corp	3980	edwqa
createid-dmcdbqa01corp	3988	edwqa
createid-dmcdbqa02corp	3996	edwqa
createid-dmcdbqa03corp	4004	edwqa
createid-dmcdbqa04corp	4012	edwqa
createid-vcfddbqa28	3412	fciread

Confirm the live UID on each host directly, rather than trusting the script alone (scripts and reality can disagree after manual edits):

ssh dmcadmqa01corp lsuser -a id dsunder

The output is the authoritative current value, for example dsunder id=3980.
While you are at it, make sure the chosen canonical UID is not already in use by a different account on any host. This is the single most important safety check:

ssh dmcadmqa01corp lsuser -a id ALL | grep 'id=3412 '

If 3412 is free (or already belongs to dsunder) on that host, you are clear to proceed. If a different login owns 3412, stop — you must resolve that collision first, otherwise the two accounts will merge.

Why the lowest UID? Choosing the earliest-assigned number is a convention, not a rule. The earliest UID is usually the one that owns the most existing files (it was created first), so standardizing on it minimizes how much data you have to re-own. Pick deliberately and document it.

Step 2 — Apply the canonical UID with chuser

On every host where the account currently has the wrong UID, change it to the canonical value with chuser. The hosts that already use 3412 need no change.

Make sure the user is logged out and has no running processes on the host you are about to change:

ssh dmcadmqa01corp ps -fu dsunder

If processes are running, stop them in your maintenance window before continuing.
Change the UID. Run this on each host where the UID is wrong (here, the QA boxes that were on 3980/3988/3996/4004/4012):

ssh dmcadmqa01corp chuser id=3412 dsunder

This rewrites the user's UID to 3412 in /etc/passwd. AIX automatically updates the ownership of the user's primary files that chuser knows about, but it does not walk the whole filesystem — that is what Step 3 is for.
Repeat the chuser command on each remaining out-of-sync host, substituting the correct hostname each time.

Important correction: a single chuser id=3412 dsunder command only fixes the host you run it on. There is no AIX command that synchronizes a UID across machines for you — you must loop over the hosts yourself (or use the script in Step 3). Do not assume one command propagates everywhere.

Step 3 — Re-own files from the old UID to the username

This is the step people forget, and it is where data corruption hides. When dsunder was UID 3980, every file they created was stamped with the number 3980, not the name. After you change the account to 3412, those files are still owned by 3980 — an orphaned number that now belongs to nobody (or, worse, to a different person if 3980 gets reused). You must find those files and re-assign them.

On the host that previously used the wrong UID, find every file still owned by the old number and re-own it to the username. Re-owning by name (not by the new number) is the safe form, because chown resolves the name to the now-correct UID:

find / -user 3980 -print | xargs chown dsunder

For paths with spaces or unusual characters, the null-delimited form is safer:

find / -user 3980 -print0 | xargs -0 chown dsunder

Or skip xargs entirely and let find do the work, which avoids argument-length limits on large trees:

find / -user 3980 -exec chown dsunder {} +
Preview first. Before re-owning anything, run the find alone to see exactly what will change — never pipe straight into chown on a production box without looking:

find / -user 3980 -print
If the old UID owned files on remote or shared filesystems (NFS, GPFS), run the re-ownership on the server that owns the storage, not on a client. Re-owning over an NFS mount can be blocked by root-squash and will only touch what that client can see.
Repeat for every old UID the account ever had. Putting it together, a per-host fix looks like this:

OLD=3980; NEW=3412; U=dsunder

chuser id=$NEW $U && find / -xdev -user $OLD -exec chown $U {} +

The -xdev flag keeps find on one filesystem so you can run it deliberately per mount and avoid chasing into /proc or remote mounts by accident.

Don't forget group ownership

The same problem exists for GIDs. If the user's files were group-owned by an old numeric GID, re-own those too:

find / -xdev -group 3980 -exec chgrp $NEW_GID {} +

You can also fix user and group in one pass with chown user:group when both need correcting.

Step 4 — Fix the source scripts so drift never returns

Correcting the running systems is only half the job. If the create-id scripts still carry the wrong numbers, the next rebuild or re-provision will reintroduce the duplicate UIDs. Edit each provisioning script so the id= value matches the canonical UID.

Update every mkuser line to the canonical UID. For example, change:

mkuser id=3980 pgrp=edwqa groups=edwqa gecos='Dejan Sunderic' home=/home/dsunder dsunder

to:

mkuser id=3412 pgrp=edwqa groups=edwqa gecos='Dejan Sunderic' home=/home/dsunder dsunder
Commit the corrected scripts to version control with a note explaining the canonical-UID decision, so future admins understand why 3412 is mandatory for this account.
Long term, move off per-host hard-coded UIDs entirely. A central identity source — LDAP, an AIX SYSTEM=LDAP stanza, or NIS — guarantees one UID per user across the whole fleet and makes this entire class of problem disappear.

Common pitfalls when you correct and synchronize UIDs in AIX

Forgetting to re-own files. Changing the UID without running find ... chown leaves a trail of orphaned files owned by a dead number — the most common cause of "the user can't read their own data" after a UID change.
Re-using a UID that already belongs to someone else. If your target UID is live on another account on any host, the two accounts merge and each can access the other's files. Always run the collision check in Step 1 first.
Running chown over an NFS mount. Root-squash will silently block or limit the change. Re-own on the storage server.
Changing the UID while the user is active. Running processes still hold the old numeric credential; new files they write can be stamped with the old number mid-operation. Do it in a maintenance window with the user logged out.
Letting find wander into /proc, /dev, or remote mounts. Use -xdev and run per filesystem so a re-ownership pass stays predictable.
Editing /etc/passwd by hand. Always use chuser — it keeps /etc/passwd and /etc/security/passwd consistent. A hand edit can desynchronize the security database.
Fixing the live systems but not the scripts. The drift comes straight back on the next rebuild. Step 4 is mandatory, not optional.

Step 5 — Verify the synchronization

After applying the change on every host, confirm the account is now consistent and no orphaned ownership remains.

Confirm the UID is identical on each host. A quick loop makes this auditable:

for h in bvsnmdbua28 dmcadmqa01corp dmcdbqa01corp; do ssh $h lsuser -a id dsunder; done

Every line should report dsunder id=3412.
Confirm no files remain under any old numeric UID. This should return nothing:

find / -xdev $ -user 3980 -o -user 3988 -o -user 3996 -o -user 4004 -o -user 4012 $ -print
Spot-check that file listings now show the name, not a number:

ls -l /home/dsunder

Ownership should read dsunder, not a bare integer.
Confirm the account still logs in and can read its data:

su - dsunder -c 'id; ls -la ~'

The id output should show uid=3412(dsunder) and the home directory should be fully readable.
If home directories are NFS-shared, verify that the name resolves correctly on a client too — the whole point of synchronization is that 3412 means dsunder everywhere.

Key Takeaways

UNIX trusts numbers, not names — permissions and ownership are keyed off the numeric UID, so mismatched UIDs across hosts silently break shared and NFS storage.
Pick one canonical UID (usually the lowest/earliest) and apply it with chuser id=<uid> <user> on every out-of-sync host — one command per host, there is no fleet-wide auto-sync.
Always re-own existing files with find / -user <oldUID> -exec chown <user> {} +; a UID change alone leaves orphaned files behind.
Check for collisions first — never reuse a UID that already belongs to a different account, and run the change in a maintenance window with the user logged out.
Fix the provisioning scripts (or move to LDAP/NIS) so the duplicate UIDs do not reappear on the next rebuild.

Frequently Asked Questions

What is the difference between a username and a UID in AIX?

The username is a human-readable label, while the UID is the numeric identity the kernel actually uses for file ownership, permissions, and process credentials. Two accounts with the same UID are effectively the same user to the operating system, regardless of having different login names. That is why synchronizing the UID — not just the name — is what fixes cross-host ownership.

Does the chuser command automatically change ownership of all my files?

No. chuser id=<uid> <user> updates the account's UID in the password database and the user's primary references, but it does not walk the entire filesystem. Files created under the old UID remain owned by that old number until you re-own them explicitly with find ... -exec chown <user> {} +.

How do I check whether a UID is already in use on an AIX host?

List all users and filter for the number with lsuser -a id ALL | grep 'id=3412 ', or query a single account with lsuser -a id <username>. Run this before assigning a canonical UID so you never merge two real accounts onto the same number.

Why do duplicate UIDs cause problems with NFS?

NFS resolves ownership by numeric UID, not by name. If a file owned by UID 3412 lives on an NFS export and a client maps 3412 to a different user, that client's user inherits access to the file. Synchronizing every host to the same UID for each account is what keeps NFS permissions correct.

If this AIX user-management walkthrough helped, subscribe to @explorenystream on YouTube for more sysadmin and troubleshooting guides.