When you delete a user account in Linux using userdel, the system's behavior regarding the user's files depends on which flags you use and how your system is configured. By default, the files remain intact but their ownership changes.

Without any special flags, userdel username will:

• Remove the user from /etc/passwd and /etc/shadow
• Keep all files owned by the deleted user
• Change ownership in file metadata to the deleted user's UID (now orphaned)

Example showing orphaned files:

$ sudo userdel testuser
$ ls -ln /home/testuser/file.txt
-rw-r--r-- 1 1001 1001 0 Jan 1 10:00 /home/testuser/file.txt

Case 1: No --remove flag
Files remain with original UID/GID. If you create a new user with the same UID, they'll automatically inherit these files.

Case 2: Using --remove (-r)
sudo userdel -r username will delete both the user and their home directory/mail spool. Any files outside these locations will remain with the orphaned UID.

Case 3: Preserving home directory
Even with -r, files in other directories (like /var/www/) keep their ownership. You might need to manually reassign them:

$ sudo find / -uid 1001 -exec chown newuser:newgroup {} +

1. Always check for files before deletion:

   
   $ sudo find / -uid 1001
   

2. Consider archiving instead of deleting:

   
   $ sudo tar -czf /backups/testuser_$(date +%F).tar.gz /home/testuser
   

3. For complete cleanup, combine multiple commands:

   
   $ sudo userdel -r testuser && \
     sudo find / -uid 1001 -delete
   

To properly reassign all files from a deleted user without knowing the original UID:

$ old_uid=$(getent passwd testuser | cut -d: -f3)
$ sudo find / -uid $old_uid -exec chown newuser:newgroup {} +

When you delete a user in Linux using userdel, the system only removes the user account entry from /etc/passwd, /etc/shadow, and /etc/group. The user's files remain intact on the filesystem, but their ownership information becomes problematic.

Files previously owned by the deleted user now reference a UID (User ID) that no longer exists in the system's user database. For example:

$ ls -l /home/deleted_user/
-rw-r--r-- 1 1001 1001 1024 Mar 15 10:00 important_file.txt

Here, UID 1001 is displayed instead of a username because the system can't map it to a valid user account.

1. Default Behavior (No Options):
userdel username keeps all files owned by the former UID

2. With -r Option:
userdel -r username removes the home directory and mail spool, but other files outside these locations remain

3. With --remove Option:
userdel --remove username attempts to remove all files owned by the user across the filesystem

Before deletion:

# Find all files owned by the user
$ find / -user username -ls
# OR by UID if you know it
$ find / -uid 1001 -ls

After deletion:

# Reassign ownership to another user
$ find / -uid 1001 -exec chown newuser:newgroup {} +
# Alternative: Delete all orphaned files
$ find / -uid 1001 -delete

When replacing a deprecated service account:

# First identify all files
$ old_uid=$(id -u old_service)
$ find / -uid $old_uid > /tmp/orphaned_files.list

# Create new service account
$ useradd -r -u $old_uid new_service

# Verify ownership transfer
$ while read file; do ls -l "$file"; done < /tmp/orphaned_files.list

Special cases to watch for:

• NFS-mounted filesystems may cache UID mappings
• Database systems often store files with service account ownership
• Containerized environments might have different UID namespace rules

For system administrators managing multiple servers:

#!/bin/bash
# Safe user deletion script
USER_TO_REMOVE="$1"
BACKUP_DIR="/backup/user_files/$USER_TO_REMOVE"

# Backup files first
mkdir -p "$BACKUP_DIR"
find / -user "$USER_TO_REMOVE" -exec cp -a --parents {} "$BACKUP_DIR" \;

# Remove user and home directory
userdel -r "$USER_TO_REMOVE"

# Report remaining files
echo "Orphaned files check:"
find / -nouser -ls | grep "$(id -u "$USER_TO_REMOVE" 2>/dev/null)"