User & Group Management

Stop breaking file ownership when changing UIDs

🧩 The Challenge

Ever had to change a user’s UID? Maybe you’re cleaning up provisioning mistakes, or consolidating accounts. You run `usermod -u`, maybe even throw in the `-m` flag, and then your user calls you because some critical script in `/opt` or old project files are suddenly “permission denied”. It’s a pain to debug, and you’ll waste hours tracking down scattered files. Nobody tells you how deep this rabbit hole goes.

💡 The Fix

There’s a simple, two-step process to ensure that when you change a user’s UID, every single file they own across the entire system gets properly re-assigned. You won’t leave orphaned files or ghost ownerships lying around.

# First, note the OLD UID for your user.
# Let's say user 'devops-guest' is currently UID 1005.
# And you want to change them to NEW UID 1010.
# Make absolutely sure the new UID (1010) doesn't conflict with another user's existing UID.

# 1. Change the user's UID and update their home directory ownership
usermod -u 1010 -m devops-guest

# 2. Find and fix any other files *still* owned by the OLD UID (1005)
# This handles files outside the home directory that usermod misses.
find / -uid 1005 -exec chown devops-guest {} +

⚙️ Why It Works

The `usermod -m` option only updates the home directory. This combination ensures that files elsewhere on the filesystem, previously owned by their old UID, get correctly reassigned to the now-renumbered user. It’s thorough, and it prevents those nasty “permission denied” surprises.

🚀 Pro-Tip: Do this with groups too! `groupmod -g <NEW_GID> <groupname>` then `find / -gid <OLD_GID> -exec chgrp <groupname> {} +`.

Linux Tips & Tricks | © ngelinux.com | 11/4/2026