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 stanza

View on GitHub (pinned to e227c27540)

Solutions

  1. Inspect the user's current groups: `lsgroup -a users <group>` / `grep ^user: /etc/group` (the provider parses /etc/group).
  2. Manually reset the list with `chuser groups=<comma-list> <user>` to drop the stale primary group the message names.
  3. Fix or remove references to deleted groups before changing gid again.
  4. 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

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


AI-assisted analysis of puppetlabs/puppet@e227c27540 (2026-08-21). Data as JSON: /api/errors/dbec32b03c658180. Report an issue: GitHub.