🚨 chage Error: 'chage: cannot change to shadow password aging information' — Cause, Fix, and Troubleshooting Guide

What this error means

chage sets password-aging fields (max age, warning, expiry) that live in /etc/shadow. This error means it could not write those fields — the account has no local shadow entry, the account is managed by a network directory rather than local files, or the shadow database is locked/immutable.

chage: cannot change to shadow password aging information for user 'appsvc'

Password aging is a common CIS/STIG hardening requirement, so this shows up while automating expiry policy across a fleet — and the fix depends on where the account actually lives.

How it manifests on the host

• sudo chage -M 90 user fails with the message above; nothing in /etc/shadow changes.
• chage -l user works for local users but errors for directory-backed ones.
• The failure appears only inside containers or minimal images.
• A hardening playbook applying aging policy fails on a subset of accounts.

System configuration causes

• No local shadow entry. The user exists in /etc/passwd (or only in a directory) but has no /etc/shadow line to update.
• Network-managed account. The user comes from LDAP/AD via SSSD/nss; aging must be set in the directory, not with local chage.
• Shadow file locked. A concurrent passwd/usermod holds /etc/shadow.lock, or /etc is read-only.
• Immutable attribute. /etc/shadow has the +i (immutable) bit set by a hardening step.
• Corrupt shadow entry with the wrong number of fields.

Interrogating the host

# Does the user have a local shadow entry at all?
sudo getent shadow appsvc          # empty => not a local shadow user
getent passwd appsvc               # where does the account come from?

# Is the account provided by a network directory?
sudo getent passwd appsvc | cut -d: -f1
systemctl is-active sssd 2>/dev/null

# Is the shadow file locked or immutable?
ls -l /etc/shadow.lock 2>/dev/null
lsattr /etc/shadow 2>/dev/null
mount | grep ' / '                  # is / (or /etc) read-only?

If getent shadow returns nothing but getent passwd shows the user, the account is not local — that is the usual cause.

Remediation

1. For a network (LDAP/AD) account, set aging in the directory, not with local chage. Use the directory’s tooling (ldapmodify, AD password policy, or SSSD-configured policy); local chage cannot write there.

2. Create the missing shadow entry for a genuinely local user (e.g. one added with useradd -p oddly or restored from a passwd-only backup):

sudo pwconv        # regenerates /etc/shadow from /etc/passwd where missing
sudo chage -M 90 -W 7 appsvc

3. Clear an immutable bit set by a hardening step, apply, then restore protection if desired:

sudo lsattr /etc/shadow
sudo chattr -i /etc/shadow
sudo chage -M 90 appsvc
# re-apply if your policy expects it: sudo chattr +i /etc/shadow

4. Remount writable / clear a stale lock if /etc is read-only or a lock lingers:

sudo rm -f /etc/shadow.lock        # only if no passwd/usermod is running
sudo mount -o remount,rw /          # for read-only rootfs cases

Hardening the host

• Do not apply local aging policy to directory-backed accounts — it silently does nothing useful and masks the real policy location.
• Editing /etc/shadow by hand risks corruption; prefer chage, passwd, and pwconv.
• Service/system accounts often should be locked (passwd -l) with no expiry rather than aged — decide policy per account type.
• If you set +i on shadow as a hardening measure, document it, or routine password changes will mysteriously fail.

Related system errors

• Auditing PAM and Password Policy with AI
• pam_faillock ‘Account Locked’ Error Guide
• CIS Benchmark Hardening for Linux Servers