Search for ownership of files recursively

[Mark Smith T-Systems]

Thsi one is a litte beyond me, I deleted users and their home directories, but what command can I use to search recursivley through the rest of the file systems, any files owned by those users ?

[Pete Randall · Accepted solution]

Use the find command

find /start_dir -type f -o joeblow -exec rm {} \;

See "man find"


Pete

[Pete Randall]

Sorry, make that "-user" not "-o"


Pete

[James R. Ferguson]

HI Mark:

# find / -nouser

See the manpages for 'find' for more information.

Regards!

...JRF...

[Pete Randall]

Oh! You already deleted them. I think James obviously has the better plan, though I also think you could still search on the uid.


Pete

[Mark Smith T-Systems]

James' idea listed every file not owned by anybody listed in the password file and I already deleted the users, so I ended up with a huge list and no way of telling which were related to the users that I deleted, and I want to see what files remain with those ownerships so I can decide to keep them or delete them.

[Mark Smith T-Systems]

find / -type f -user
doesnt work either because the user has already been removed from the system :-(

[James R. Ferguson]

Hi (again) Mark:

If you have deleted the account (name) and don't want every unowned file (that is, one's whose uid don't map to a password database) then you need to know the UID that represented the account you deleted:

# find / -user 1000

...will return any files and directories owned by uid=1000.

When you specified a name, like:

# find / -user mark

...a mapping of "mark" to its uid was attempted but the absence of a named account voided the operation.

Regards!

...JRF...

[Pete Randall]

Typically, James has put into real, understandable English what I was implying when I referred specifically to uid rather than uname. Perhaps you can pick out a likely uid from your long last of unowned files.


Pete

[TwoProc]

I would just recover an old version of the /etc/passwd file into somewhere. Then, I'd copy old whomever's line back into /etc/passwd.
Then I'd delete the recovered one. Then I'd go and find all of whomevers stuff and determine what to do with it. By this, I mean I wouldn't just go and delete all of his files. What if they are in production code areas?? After this, then delete him once again from the /etc/passwd file.

Or, if you don't like putting him back in the /etc/password file, then just look up his uid and do your find from there.

But, I'd be careful of just kicking off a iterative delete from the server without looking at ownership.

Also, FWIW. Deleting old user accounts is a problem for security. Just lock them and keep them in their own section of GONE users, and then do the right thing (whatever that is) for their files and remove their home directories. Point their shell to /dev/null or something that will never run. Reason? If you reuse that uid number for a new user, they will automatically inherit all files previously owned by the previous owner possibly left on the server. Some of those files could contain secure data not meant for the general user/developer population. The possibility goes up when you've got lots of servers and you believe you *already know* which servers he or she used.

[James R. Ferguson]

Hi (again) Mark:

Lastly, once you decide what 'uid' represents the deleted name, you can leverage 'find' to transfer the ownership of the orphaned files and directories to a valid account:

# find / -user 1000 -exec chown newuser:newgroup {} \+

This assumes that it was uid=1000 that was deleted from the password database and that "newuser" and "newgroup" are valid mappings in your current database.

NOTICE that the 'chown' is NOT recursive. You probably want to change the ownership of directories and files found but certainly do not want to blindly recursively change the ownerships of all files found in a particular directory!

Regards!

...JRF...

[Mark Smith T-Systems]

I had many good replies, thank you.