🚨 Linux Error: chown: invalid user: '<name>' — Cause, Fix, and Troubleshooting Guide

Summary

chown: invalid user: '<name>' means chown could not resolve the name you supplied to a UID through the name service (NSS) — /etc/passwd, plus LDAP/SSSD/winbind if configured. The file is never touched; chown fails before changing anything. It is a name-resolution problem: either the user genuinely does not exist, the name is mistyped, or the directory service that would resolve it is unreachable.

Common Symptoms

• chown appuser:appgroup /srv/app returns chown: invalid user: 'appuser' (or invalid group) and changes nothing.
• A deploy script or Ansible task fails on a chown/file step referencing a user that is not present yet.
• The user exists on one host but not the one running the command (drift between machines).
• chown 1001:1001 file works while chown appuser:appgroup file fails — confirming a name-lookup issue, not a permissions one.

Most Likely Causes of the ‘chown: invalid user: ’ Error

chown: invalid user: '<name>' fires when NSS returns no entry for the name. Common production causes, most frequent first:

1. The user was never created on this host — the account exists in the image/other nodes but not here (config drift).
2. A typo or wrong case in the username, or user:group written as user.group/user;group.
3. The order of the deploy is wrong — the chown runs before the useradd step that creates the account.
4. A directory service (LDAP/AD/SSSD/winbind) is down or misconfigured, so remote users that normally resolve now do not.
5. You meant a numeric UID that has no name — use the numeric form so chown does not try to resolve a name.

Quick Triage

# Does NSS resolve the name at all?
getent passwd <name> || echo "user '<name>' does not resolve"
id <name> 2>&1
# Group side (chown user:group resolves both)
getent group <group> || echo "group '<group>' does not resolve"

If getent passwd <name> prints nothing, that is the confirmed cause — the name is not resolvable on this host.

Diagnostic Commands

# Authoritative NSS lookup (covers files + LDAP/SSSD/winbind)
getent passwd <name>
getent group <group>

Empty output = the name does not exist in any configured source.

# Full account resolution, including UID/GID
id <name>

id: '<name>': no such user mirrors the chown failure.

# Is it only missing from local files, or from remote sources too?
grep -w '<name>' /etc/passwd
grep -w '<group>' /etc/group

Present in /etc/passwd but failing getent suggests a corrupt line or nsswitch issue; absent from both means create it or fix the directory service.

# Which sources does NSS consult?
grep -E '^(passwd|group):' /etc/nsswitch.conf

Expect e.g. passwd: files sss — if sss/ldap is listed but the service is down, remote users won’t resolve.

# If a directory service is in play, is it healthy?
sudo sss_cache -E 2>/dev/null; getent passwd <name>   # bust SSSD cache and retry
systemctl status sssd 2>/dev/null | head

# Confirm the intended numeric IDs (to use the numeric form)
getent passwd | awk -F: '$3>=1000{print $1, $3}' | sort -k2 -n | tail

Fix / Remediation

1. Fix a typo — re-run with the correct, case-exact name and the right separator (user:group, colon not dot):

   getent passwd appuser && sudo chown appuser:appgroup /srv/app

2. Create the user/group if it should exist here (the common deploy-drift fix). Use a fixed UID/GID so it matches other hosts:

   sudo groupadd -g 1500 appgroup 2>/dev/null
   sudo useradd -u 1500 -g appgroup -M -s /usr/sbin/nologin appuser
   sudo chown appuser:appgroup /srv/app

3. Chown by numeric UID:GID when the account is intentionally nameless (e.g. container-owned files, a UID that only exists in another namespace):

   sudo chown 1500:1500 /srv/app

4. Change ownership only from a specific old owner (safe, targeted) with --from:

   sudo chown --from=olduser:oldgroup 1500:1500 -R /srv/app

5. If a directory service is the source, restore/refresh it rather than creating a local shadow account:

   Warning: Do not paper over a down LDAP/SSSD by creating a conflicting local user with a different UID — that causes ownership mismatches later. Fix the directory service first.

   sudo systemctl restart sssd
   sudo sss_cache -E
   getent passwd <name>    # should now resolve

6. In Ansible/automation, order tasks correctly — create the user before any task that chowns to it, or reference the numeric UID.

Validation

# The name now resolves
getent passwd appuser && id appuser
# The chown succeeds and ownership is correct
sudo chown appuser:appgroup /srv/app && ls -ld /srv/app
stat -c '%U:%G (%u:%g)' /srv/app

A resolving getent, a chown that returns 0, and the expected owner in ls -ld/stat confirm the fix.

Prevention

• Provision users and groups with fixed UIDs/GIDs via config management (Ansible user/group, or a shared LDAP source) so every host resolves the same names.
• In deploy playbooks, always create the account before any chown/file task, or reference the numeric UID to avoid ordering bugs.
• Keep local system UIDs and directory-service UIDs in non-overlapping ranges to prevent collisions.
• Monitor SSSD/LDAP health so remote user resolution failures are caught before they break chowns and logins.
• Prefer numeric ownership for container-mounted volumes, where the name may not exist on the host.

Related Errors

• Linux Error: Permission denied
• Linux Error: Operation not permitted
• Linux Error: passwd: Authentication token manipulation error
• Linux Error: su: Authentication failure

Final Notes

chown: invalid user: '<name>' is a lookup failure, not a permission failure — chown refuses to run because NSS has no UID for the name. Confirm with getent passwd/id, then either fix the typo, create the account with a stable UID, use the numeric form, or repair the directory service. Provisioning users through config management keeps the name resolvable everywhere and makes this error disappear.

Want faster Linux incident response? Use DevOps AI Toolkit to turn production errors into clear diagnostics, remediation steps, and reusable runbooks.