— LiveStream

Removing AIX groups and user accounts safely means locking and disabling the account first, transferring or archiving its files, then deleting the user before you delete any group that the user belonged to. On IBM AIX this is done with native commands such as chuser, rmuser and rmgroup, ideally backed by version control of your provisioning scripts so every change is auditable and reversible.

This guide walks through the full lifecycle the way a careful UNIX administrator would run it in a production environment: how to find what a user owns, how to disable an account without losing data, how to remove the account cleanly, and how to retire a group only once nothing depends on it. It also fixes a common but risky habit seen in homegrown ID-provisioning scripts and shows the verification steps that prove the cleanup actually worked.

Why Removing AIX Groups and User Accounts Needs a Process

On AIX, a user account and a group are not isolated objects. A user has a primary group and zero or more secondary (supplementary) groups, owns files across many filesystems, may have running processes, cron jobs, and entries in access-control lists. Deleting things in the wrong order leaves orphaned files owned by a numeric UID, broken group ownership, and sometimes a group you cannot remove because it is still someone's primary group.

The golden rule is disable, then audit, then delete. Locking the account stops new logins immediately and buys you time to confirm nobody and nothing still needs it. Only after the user is gone do you consider removing the group. This sequencing is the difference between a clean offboarding and a midnight incident.

The Files and Concepts Behind AIX Accounts

AIX stores account data in a small set of well-defined files. Knowing them helps you understand what each command actually changes:

• /etc/passwd — user name, UID, primary GID, home directory and shell.
• /etc/security/user — per-user attributes such as account_locked, login, password rules and expiry.
• /etc/security/passwd — the hashed passwords (shadow data).
• /etc/group — group name, GID and the list of secondary members.
• /etc/security/group — group administration attributes (admins, who may join).

You should almost never hand-edit these files. The AIX high-level commands (mkuser, chuser, rmuser, mkgroup, rmgroup) keep all of these files consistent with each other and update the system object database. Editing the files directly invites mismatches that the commands would have prevented.

Step-by-Step: Disabling an AIX User Account Safely

Before you remove anything, lock the account so it cannot be used while you investigate. Run every command below as root (or via sudo/RBAC if your site uses it).

1. Lock the account. This is the single most important step and it is fully reversible:
   chuser account_locked=true gzhang
2. Block all login paths. Locking covers interactive login, but also deny remote and scheduled access explicitly:
   chuser login=false rlogin=false su=false gzhang
3. Kill active sessions and processes. A locked account can still have live processes. Identify and stop them:
   ps -fu gzhang
kill -TERM $(ps -u gzhang -o pid=) (escalate to kill -9 only if needed).
4. Remove scheduled work. Check and clear the user's cron and at jobs so nothing fires after removal:
   crontab -l gzhang
crontab -r gzhang
5. Confirm the lock took effect:
   lsuser -a account_locked login gzhang

At this point the user cannot log in, has no running processes and no scheduled jobs, but the home directory and all owned files are untouched. Many teams stop here for a defined retention window (for example 30 to 90 days) before deleting, which is a sound, low-risk policy.

Step-by-Step: Auditing What the User Owns

Never delete a user before you know what would be left behind. Capture an inventory first:

1. Record the account's identity so you can find orphaned files later by number:
   id gzhang
lsuser -a id pgrp groups home gzhang
2. Find every file the user owns across mounted local filesystems:
   find / -fstype jfs2 -user gzhang -xdev 2>/dev/null (repeat per filesystem, or omit -xdev with care).
3. Archive the home directory and key data before deletion:
   tar -cvf /backup/gzhang_home.tar /home/gzhang
4. Decide ownership of remaining files. Either archive them, delete them, or reassign them to a successor or service account with chown.

This audit is what prevents the classic failure mode where, weeks after an offboarding, someone runs ls -l and sees files owned by a bare UID like 1492 because the name no longer maps to anything.

Step-by-Step: Removing the AIX User Account

Once the account is locked, audited and backed up, remove it. AIX gives you two important choices about the home directory.

1. Remove the account but keep the home directory (the safest default — you can still recover data):
   rmuser gzhang
2. Remove the account and its home directory and mailbox in one step (only after you have a verified backup):
   rmuser -p gzhang

The -p flag also removes the user's security and password attributes; without it some entries can linger. After removal, deal with any remaining owned files you found during the audit — reassign or delete them so nothing stays orphaned:

find / -nouser -xdev 2>/dev/null lists files whose owning UID no longer maps to a name; clean these up deliberately.

Step-by-Step: Removing an AIX Group

Only remove a group after the users that depend on it are gone or reassigned. AIX will refuse to remove a group that is still some user's primary group, and that protection is there for a reason.

1. List the group's members and its GID before touching it:
   lsgroup -a id users uatwrite
2. Check whether it is anyone's primary group. This is the step most people skip:
   lsuser -a pgrp ALL | grep uatwrite
3. Reassign any users whose primary group is the doomed group to a valid primary group first:
   chuser pgrp=staff someuser
4. Remove the group:
   rmgroup uatwrite
5. Reclaim ownership of leftover files that still carry the old GID:
   find / -nogroup -xdev 2>/dev/null then chgrp them to a valid group.

Removing the group only edits the group definition; it does not change the group ownership stamped on existing files. Those files keep the now-defunct numeric GID until you re-stamp them, which is exactly why the -nogroup sweep matters.

Managing Group Membership Through Provisioning Scripts

Many enterprises do not call mkgroup by hand. Instead they keep a central provisioning script — often a Korn shell file such as mkgroup_user.ksh in a shared directory like /homecomm/nsek/create_id_grp — that defines every group and ID per server. A typical block looks like this:

Here the -A flag makes the invoking user the group administrator and id= pins an explicit, stable GID. When you decommission the uatwrite group, the workflow is:

1. Comment out the relevant line in the script so the group is never recreated on the next run:
   # mkgroup -A id=1264 uatwrite
2. Actually remove the live group on the server (commenting the script does nothing to the running system on its own):
   rmgroup uatwrite
3. Commit the script change to version control with a clear message so the removal is auditable.

The critical correction: commenting a line out of the provisioning script and running rmgroup are two completely separate actions. The comment prevents future re-creation; the rmgroup removes what exists right now. Doing only one of them is the most common mistake in this pattern — comment-only leaves the group live forever, and rmgroup-only means the next script run silently recreates it.

Common Pitfalls When Removing AIX Groups and User Accounts

• Deleting before locking. Removing a user that is still logged in or running batch jobs can corrupt that user's work and leave half-written files. Lock and drain first.
• Reusing a UID or GID too soon. If orphaned files remain and you later create a new account with the same numeric ID, the new user instantly "owns" the old user's files. Always sweep -nouser/-nogroup before recycling IDs.
• Removing a primary group. rmgroup will fail (or leave users in a broken state) if the group is still a primary group. Reassign with chuser pgrp= first.
• Hand-editing /etc/passwd or /etc/group. This desynchronizes the security files. Use rmuser/rmgroup so every backing file stays consistent.
• Forgetting cron, at and ACLs. A removed user can still have cron entries firing as a numeric UID, and POSIX/NFSv4 ACLs can still reference the old ID. Clear scheduled jobs and review ACLs on sensitive paths.
• Comment-without-remove. As above, editing the provisioning script does not change the running system. Always pair the comment with the live rmgroup.

Verification: Proving the Cleanup Worked

A removal is not finished until you can prove nothing is left. Run these checks after deleting a user and a group:

1. The user is gone: lsuser gzhang should return 3004-687 User "gzhang" does not exist.
2. The group is gone: lsgroup uatwrite should report that the group does not exist.
3. No login is possible: attempting su - gzhang must fail.
4. No orphaned files remain: find / -nouser -xdev 2>/dev/null and find / -nogroup -xdev 2>/dev/null return nothing for the recycled IDs.
5. No scheduled work survives: ls -l /var/spool/cron/crontabs/ | grep gzhang shows nothing.
6. The script will not recreate it: grep the provisioning script to confirm the line is commented:
   grep uatwrite /homecomm/nsek/create_id_grp/mkgroup_user.ksh

When all six checks pass, the account and group are fully retired with no residue and no risk of accidental re-creation.

A Note on Modern AIX and RBAC

The commands above are current and supported on modern AIX (7.2 and 7.3). On hardened systems that use Role-Based Access Control (RBAC) or a centralized directory (LDAP), the same logical steps apply but you may run them through an RBAC role rather than raw root, and group/user data may live in LDAP rather than the local files. In that case, removal is performed through your directory tooling, and the local rmuser/rmgroup only affect local accounts. Always confirm which registry an account lives in with lsuser -R files versus lsuser -R LDAP before deleting.

Key Takeaways

• Always disable before deleting: chuser account_locked=true username is reversible and stops access instantly.
• Audit and back up first: inventory owned files with find -user, archive the home directory, then remove with rmuser (add -p only with a verified backup).
• Remove groups last: a group cannot be removed while it is anyone's primary group, so reassign with chuser pgrp= before rmgroup.
• Commenting a provisioning script is not removal: pair the commented mkgroup line with a live rmgroup so the group is both gone now and never recreated.
• Verify with the orphan sweep: find / -nouser and find / -nogroup catch the leftover files that silently break IDs when you recycle UIDs and GIDs.

Frequently Asked Questions

How do I remove a user but keep their files on AIX?

Run rmuser username without the -p flag. This deletes the account definition but leaves the home directory and owned files in place. The files will then show a numeric UID instead of a name, so either reassign them with chown or archive them afterward.

Why does rmgroup fail with the group still in use?

AIX refuses to remove a group that is still a user's primary group. Find those users with lsuser -a pgrp ALL, reassign each to a valid primary group using chuser pgrp=staff username, and then rmgroup will succeed.

What is the difference between locking and removing an AIX account?

Locking with chuser account_locked=true is reversible: it blocks login but preserves the account, its UID and all files. Removing with rmuser is permanent: the account definition is gone and any recovery depends on backups. Best practice is to lock first and only remove after a retention window.

How do I find files owned by a deleted user or group?

Use find / -nouser -xdev 2>/dev/null to locate files whose owning UID no longer maps to a name, and find / -nogroup -xdev 2>/dev/null for files with an orphaned GID. Reassign them with chown and chgrp before you ever recycle the old IDs.

For more practical UNIX and AIX system administration walkthroughs, subscribe to our YouTube channel @explorenystream.