puppetlabs/puppet · error · Puppet::Error
Could not reset the groups property back to %{cur_groups} af
Error message
Could not reset the groups property back to %{cur_groups} after setting the primary group on %{resource}[%{name}]. This means that the previous primary group of %{old_pgrp} and the new primary group of %{new_pgrp} have been added to %{cur_groups}. You will need to manually reset the groups property if this is undesirable behavior. Detail: %{detail} What it means
Raised by Puppet's AIX user provider after a primary-group (gid) change succeeded but the follow-up reset of the groups property failed. AIX's chuser automatically adds both old and new primary groups to the supplementary list when pgrp changes, so the provider snapshots groups, sets gid, then restores groups; if that restore raises Puppet::Error, this message reports the divergence and tells you to fix it manually.
Source
Thrown at lib/puppet/provider/user/aix.rb:155
# the resource methods (property getters + setters for our mapped
# properties + a getter for the attributes property).
mk_resource_methods
# Setting the primary group (pgrp attribute) on AIX causes both the
# current and new primary groups to be included in our user's groups,
# which is undesirable behavior. Thus, this custom setter resets the
# 'groups' property back to its previous value after setting the primary
# group.
def gid=(value)
old_pgrp = gid
cur_groups = groups
set(:gid, value)
begin
self.groups = cur_groups
rescue Puppet::Error => detail
raise Puppet::Error, _("Could not reset the groups property back to %{cur_groups} after setting the primary group on %{resource}[%{name}]. This means that the previous primary group of %{old_pgrp} and the new primary group of %{new_pgrp} have been added to %{cur_groups}. You will need to manually reset the groups property if this is undesirable behavior. Detail: %{detail}") % { cur_groups: cur_groups, resource: @resource.class.name, name: @resource.name, old_pgrp: old_pgrp, new_pgrp: value, detail: detail }, detail.backtrace
end
end
# Helper function that parses the password from the given
# password filehandle. This is here to make testing easier
# for #password since we cannot configure Mocha to mock out
# a method and have it return a block's value, meaning we
# cannot test #password directly (not in a simple and obvious
# way, at least).
# @api private
def parse_password(f)
# From the docs, a user stanza is formatted as (newlines are explicitly
# stated here for clarity):
# <user>:\n
# <attribute1>=<value1>\n
# <attribute2>=<value2>\n
#
# First, find our user stanzaView on GitHub (pinned to e227c27540)
Solutions
- Inspect the user's current groups: `lsgroup -a users <group>` / `grep ^user: /etc/group` (the provider parses /etc/group).
- Manually reset the list with `chuser groups=<comma-list> <user>` to drop the stale primary group the message names.
- Fix or remove references to deleted groups before changing gid again.
- Re-run Puppet afterwards and confirm the user converges to the manifest state.
Example fix
# manual remediation on the AIX node # before: primary group change left 'oldgrp,newgrp' appended chuser groups=appgrp,webgrp deploy grep '^deploy:' /etc/group # verify membership matches manifest
Defensive patterns
Strategy: try-catch
Validate before calling
# before changing gid, confirm every current supplementary group still exists
File.readlines('/etc/group').map { |l| l.split(':').first }
missing = cur_groups.split(',') - existing_groups
Puppet.warning "stale groups: #{missing}" unless missing.empty? Try / catch
begin
provider.gid = new_gid
rescue Puppet::Error => e
raise unless e.message.start_with?('Could not reset the groups property')
# compensate: rewrite the supplementary list to the intended value
Puppet::Util::Execution.execute(['chuser', "groups=#{cur_groups}", resource[:name]])
end Prevention
- Ensure groups referenced by a user are managed (and present) before any gid change.
- Avoid changing gid and group membership in the same transaction on AIX unless required.
- After gid changes, audit /etc/group membership for duplicated primary groups.
When it happens
Trigger: Changing `gid` on an AIX user whose current supplementary groups are invalid at reset time (e.g., a listed group was deleted concurrently, membership limits exceeded, or lsecf/stanza errors from chuser), causing the `self.groups = cur_groups` inside gid= to fail after set(:gid, value) succeeded.
Common situations: Modules managing both gid and groups on AIX; a group referenced by the user removed earlier in the same run; concurrent manual admin changes to the user during the Puppet run; long supplementary lists tripping AIX limits.
Related errors
- Invalid value %{groups}: Groups must be comma separated!
- Invalid value %{value}: %{property} must be an Integer!
- Cannot have both 'forcelocal' and 'ia_load_module' at the sa
- Could not set %{property} on %{resource}[%{name}]: %{detail}
- chpasswd said #{output}
AI-assisted analysis of puppetlabs/puppet@e227c27540 (2026-08-21).
Data as JSON: /api/errors/dbec32b03c658180.
Report an issue: GitHub.