Hi robcase0 & ab,
Quote Originally Posted by ab View Post
4. When you delete a user, fix the user-owner. You can do this easily
with the 'find' command which is used to find users owned by a now
non-existent UID and then run a command to change ownership (chown) to
somebody else... maybe a service account made just for this purpose, or
'root' if nothing else.
This option "4" is what looks like the right approach to me: User management needs properly defined *processes* both for creating and deleting users. Like when creating a new user, you need to set up stuff like directory entries, home dirs, group memberships and alike, you'll have to properly "delete" users from your system, in a coordinated way.

Leaving dangling files is definitely the worst option - diverging accounts (leaving independent user entries on single servers) create a high risk of messing up permissions later (i.e. when you centrally re-use the numeric ID for a new account, which would give the new user access to the old files).

Such processes should also take into account that there may be resources that *require* the old account to be kept (like entries in a history or in backups, which you cannot delete), hence keeping the ID available but disabling its use for logins is the typical (and proper) approach. But this still will not forfeit the necessity to re-own (or delete) those files: If they are kept because their content is needed, a new owner is to be found. If you no longer need the content... delete the files. Proper clean-up process.

Suggestion 1 to 3 will most probably help with the *technical* problem described by robcase0, but IMO that technical problem is only the consequence of an organizational problem up front. Fix that one and keep the technical problem as a reminder, in case the organizational problem wasn't fixed for all instances