puppetlabs/puppet · error · Puppet::Error

Could not set password on #{@resource.class.name}[#{@resourc

Error message

Could not set password on #{@resource.class.name}[#{@resource.name}]: #{detail}

What it means

Wrapper error from Puppet's AIX user provider: the password setter rescues the Puppet::ExecutionFailure raised when chpasswd emits output (including the 'chpasswd said ...' case) and re-raises it as Puppet::Error prefixed with the resource type and title, attaching the original backtrace. It is the user-facing form of any AIX password-set failure.

Source

Thrown at lib/puppet/provider/user/aix.rb:237

      # Options '-e', '-c', use encrypted password and clear flags
      # Must receive "user:enc_password" as input
      # command, arguments = {:failonfail => true, :combine => true}
      # Fix for bugs #11200 and #10915
      cmd = [self.class.command(:chpasswd), *ia_module_args, '-e', '-c']
      execute_options = {
        :failonfail => false,
        :combine => true,
        :stdinfile => tempfile.path
      }
      output = execute(cmd, execute_options)

      # chpasswd can return 1, even on success (at least on AIX 6.1); empty output
      # indicates success
      if output != ""
        raise Puppet::ExecutionFailure, "chpasswd said #{output}"
      end
    rescue Puppet::ExecutionFailure => detail
      raise Puppet::Error, "Could not set password on #{@resource.class.name}[#{@resource.name}]: #{detail}", detail.backtrace
    ensure
      if tempfile
        # Extra close will noop. This is in case the write to our tempfile
        # fails.
        tempfile.close()
        tempfile.delete()
      end
    end
  end

  def create
    super

    # We specify the 'groups' AIX attribute in AixObject's create method
    # when creating our user. However, this does not always guarantee that
    # our 'groups' property is set to the right value. For example, the
    # primary group will always be included in the 'groups' property. This is
    # bad if we're explicitly managing the 'groups' property under inclusive

View on GitHub (pinned to e227c27540)

Solutions

  1. Unwrap the message: the 'Detail'/inner text contains the chpasswd output — fix that root cause first.
  2. Confirm /usr/sbin/chpasswd (LAM path) exists and the agent runs with sufficient privileges (root).
  3. Align hash format with /etc/security/policy.cfg or adjust the policy, then re-run.
  4. Test the exact operation on the node: `echo 'user:crypthash' | chpasswd -e -c`.
Defensive patterns

Strategy: try-catch

Validate before calling

File.exist?('/usr/bin/chpasswd') or raise 'chpasswd missing'
Process.uid.zero? or raise 'password management requires root'

Try / catch

begin
  provider.password = crypted
rescue Puppet::Error => e
  if e.message =~ /Could not set password on/
    # inner 'Detail:' holds chpasswd output; branch on policy vs execution failure
    inner = e.message[/Detail: (.*)/, 1]
    report_password_failure(inner)
  end
  raise
end

Prevention

When it happens

Trigger: Any `password =>` sync on an AIX user where the underlying chpasswd invocation fails or prints diagnostics: policy rejection, unsupported hash format, user stanza issues, or genuine execution errors (command missing, permissions).

Common situations: Same contexts as the chpasswd failure — mismatched hash algorithms vs policy.cfg, strict pwdcheck policies, AIX 6.1 quirks — plus missing /usr/bin/chpasswd in a minimized AIX image.

Related errors


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