— LiveStream

Creating AIX groups is done with the mkgroup command, which adds a group to /etc/group (and /etc/security/group) with an administrator-assigned Group ID (GID). The key to a clean, repeatable environment is to assign each group a consistent GID across every server so that file ownership, NFS exports, and access controls behave identically everywhere.

This guide covers the full workflow for creating AIX groups: how the command works, how to choose and track GIDs, how to standardize group creation across a fleet of LPARs using reusable scripts, the pitfalls that cause permission chaos, and how to verify every change. It corrects a few common mistakes seen in homegrown procedures and notes the modern, safer equivalents.

The problem: inconsistent groups break access control

On a single AIX box, you could create groups ad hoc and never notice a problem. The trouble starts the moment you have multiple servers sharing data — through NFS, shared storage, rsync, or a DR pair. UNIX permissions are stored on disk as numeric IDs, not names. The directory listing you see with names is just a lookup; the kernel only ever compares the numeric GID.

If the group uatwrite is GID 1264 on one server but GID 1290 on another, a file owned by group uatwrite on the first server appears to belong to a completely different group on the second. Members lose access they should have, and unrelated users may suddenly gain it. That is why the single most important rule when creating AIX groups across a fleet is: reuse the same GID for the same group name on every server.

The mkgroup command explained

The mkgroup command is the supported AIX tool for adding a new group. It updates the user database (/etc/group, /etc/security/group) atomically and respects AIX security stanzas. The general syntax is:

1. mkgroup [ -a ] [ -A ] [ attribute=value ... ] GroupName

The most useful flags and attributes are:

• id=<number> — sets the GID explicitly. Always specify this so the number is predictable and matches your other servers. If you omit it, AIX picks the next free GID, which will drift between machines.
• -A — marks the calling user as an administrator of the group (this populates the admin=true attribute). It does not mean “administrative group.” This is a frequent point of confusion.
• -a — creates an administrative group (a group that only root or a group administrator can manage). Note the lowercase -a versus uppercase -A — they are different.
• adms=user1,user2 — names the users allowed to administer the group's membership.
• users=user1,user2 — seeds the initial membership list at creation time.

A typical, fully specified command looks like this:

1. mkgroup -A id=1264 uatwrite

That creates a group named uatwrite with GID 1264 and records the running user as a group administrator. To create it with members already in place:

1. mkgroup id=1264 users=appusr,batchusr,etluser uatwrite

Step-by-step: creating AIX groups with a consistent GID

The following workflow assumes a shared tracking file that records the last GID used, plus a set of per-purpose scripts that hold the actual mkgroup lines per server. This pattern keeps a whole estate of AIX LPARs in sync. Run these commands as root (or via sudo).

1. Go to your group-management directory. Keep all the tracking files and scripts in one controlled location, for example: cd /admin/create_id_grp
2. Read the last GID used. A simple counter file avoids collisions: cat last_grp_num — suppose it returns 1263.
3. Pick the next number. The next free GID is 1264. Before committing to it, confirm it is genuinely unused everywhere (see verification below).
4. Check whether the group already exists on another server. If uatwrite already exists in the estate, reuse its existing GID instead of allocating a new one. Only allocate a fresh number for a brand-new group name.
5. Edit the appropriate script for the group's purpose. Group the mkgroup lines by function so they are easy to audit — for example mkgroup_usr.ksh for user groups, mkgroup_adm.ksh for admin groups, mkgroup_read.ksh for read-only groups, plus mkgroup_batch.ksh, mkgroup_instance.ksh, and mkgroup_etl.ksh for their respective roles. Add the line under the correct server's section header.
6. Add the line under the target server heading. For example, to add uatwrite on server opfqa02, edit mkgroup_usr.ksh so its opfqa02 block reads:
   • # opfqa02
   • mkgroup -A id=1258 biouctl
   • mkgroup -A id=1263 uatread
   • mkgroup -A id=1264 uatwrite
7. Run the command on the target server. Either execute the script or copy the single line and run it directly on opfqa02: mkgroup -A id=1264 uatwrite
8. Update the counter file so the next allocation does not clash: write the new value (1264) into last_grp_num. From the shell: echo 1264 > last_grp_num

Important correction: some older procedures reference a filename like mkgroup_user.ksh in one place and mkgroup_usr.ksh in another. Pick one canonical name and use it consistently — a typo here means an admin edits the wrong file and the change silently never runs. Standardize the script names before you scale this out.

Choosing safe GID ranges when creating AIX groups

Numbers matter. AIX (like other UNIX systems) reserves low IDs for the operating system. Allocating an application GID that overlaps a system group is one of the worst self-inflicted outages you can cause.

Set a documented floor — for instance “all custom groups start at 1000” — and let the counter only ever move upward. Decommissioned GIDs should be retired, not recycled, because old files on tape or DR volumes may still carry that numeric owner.

Verifying the group was created correctly

Never trust that a command worked just because it returned no error. Verify on the actual server, every time. Use these checks after creating AIX groups:

1. Confirm the group resolves to the right GID: lsgroup uatwrite — this prints the group's attributes including id=1264.
2. Show just the ID: lsgroup -a id uatwrite
3. Check the raw entry: grep '^uatwrite:' /etc/group — you should see a line like uatwrite:!:1264: (the trailing field is the comma-separated member list).
4. Confirm the GID is unique — no two names should share a number: awk -F: '{print $3}' /etc/group | sort | uniq -d (this should print nothing).
5. Verify it matches the other servers: run lsgroup -a id uatwrite on each box and confirm the GID is identical everywhere.

To verify a user's effective group membership after you add people, run id username and groups username. Remember that a user must log out and back in (or start a fresh session) before a new group membership takes effect.

Common pitfalls when creating AIX groups

These are the mistakes that turn a five-minute task into a permissions incident:

• Different GIDs on different servers. The number-one cause of cross-server access failures. Always reuse the same GID for the same group name.
• Forgetting to update the counter file. Two admins both read 1263, both allocate 1264, and now two groups collide. Update last_grp_num immediately, ideally in the same change.
• Confusing -A with -a. Uppercase -A records you as the group's administrator; lowercase -a makes the group itself administrative. They are not interchangeable.
• Overlapping a reserved system GID. Reusing a low number can break system, security, or staff ownership and lock you out. Stay in your documented application range.
• Hand-editing /etc/group directly. A stray character corrupts the file for every user. Always use mkgroup / chgroup / rmgroup, which validate and lock the database.
• Recycling a retired GID. Old archives still reference the number; reusing it grants the new group accidental ownership of restored files.
• No backup before bulk changes. Before running a batch script, snapshot the security files: cp -p /etc/group /etc/group.bak.$(date +%Y%m%d) and likewise /etc/security/group.

Managing AIX groups after creation

Creating the group is only the start. The companion commands round out the lifecycle:

• Add or change attributes / members: chgroup users=appusr,newusr uatwrite (this replaces the member list — include existing members) or change the GID with chgroup id=1300 uatwrite.
• List all groups and IDs: lsgroup ALL or just the IDs with lsgroup -a id ALL.
• Remove a group: rmgroup uatwrite — this does not delete files owned by that GID, so clean those up separately.
• Set a user's primary vs. supplementary groups: use chuser pgrp=uatwrite secgroups=uatread,staff appusr.

If you prefer a menu-driven approach, AIX's SMIT (System Management Interface Tool) wraps all of these. The fast path is smitty mkgroup for creation and smitty chgroup for changes — SMIT calls the same underlying commands and logs the exact command line to smit.script, which is handy for building your repeatable scripts.

The modern, safer way to standardize groups

The shared-counter-plus-ksh-scripts pattern works, but it relies on humans not making mistakes. On a larger or audited estate, consider these improvements while still using mkgroup under the hood:

• Centralized identity. Bind AIX to LDAP (or RFC 2307 / Active Directory) so a group and its GID are defined once and resolved identically on every host. This eliminates per-server drift entirely.
• Configuration management. Drive group definitions from Ansible (the group module supports AIX) or a similar tool, with the desired GID declared in version control. The tool becomes the source of truth instead of a hand-edited counter file.
• Version-control the scripts. If you keep the .ksh approach, put the scripts and last_grp_num in Git so every allocation is reviewed and auditable, and collisions are caught at merge time.

These approaches give you the same outcome — one group name, one GID, everywhere — with far less room for human error.

Key Takeaways

• Use mkgroup id=<GID> <name> and always specify the GID explicitly so it is predictable across servers.
• Reuse the same GID for the same group name on every host — the kernel compares numbers, not names, so drift breaks shared-storage access.
• Track allocations with a counter file (or version control) and update it immediately to prevent two admins claiming the same number.
• Stay in a safe range (typically 1000+) to avoid clobbering reserved system GIDs, and never recycle retired numbers.
• Verify every change with lsgroup and /etc/group, and prefer LDAP or Ansible for fleet-wide consistency over hand-edited scripts.

Frequently Asked Questions

What is the difference between mkgroup -A and mkgroup -a in AIX?

Uppercase -A sets the user who runs the command as an administrator of the new group (the admin=true attribute). Lowercase -a creates an administrative group, which can only be managed by root or by named group administrators. They are distinct flags — check the case carefully.

How do I find the next available GID on AIX?

List existing IDs with lsgroup -a id ALL and pick the next unused number above your documented floor (commonly 1000). If you maintain a counter file such as last_grp_num, read it, increment it, and write the new value back. Always confirm the number is free on all servers before assigning it.

How do I add a user to an AIX group I just created?

Use chuser groups=staff,uatwrite username to set the user's group list, or set the primary group with chuser pgrp=uatwrite username. You can also seed members at creation time with mkgroup users=user1,user2 uatwrite. The user must start a new login session for the change to take effect; verify with id username.

Can I create an AIX group with a specific group ID number?

Yes — that is exactly what the id attribute is for: mkgroup id=1264 uatwrite. Specifying the GID explicitly is strongly recommended so the same group resolves to the same number on every server in your environment.

If this guide helped, subscribe to @explorenystream on YouTube for more sysadmin and tech walkthroughs.