Finding User Files, Alternative?

[Peter_17]

Hi All...

I'm in the process of removing many old departed users from a system which has multiple, very large file systems. I currently use the find command to track down files which may be owned by the user to be deleted, but it takes an extreemly long time. Is there an alternative way to find files owned by a user on a system?

Any and all help appreciated.

Thanks,

Pete

[Tracey]

Depending on the amount of users you have to remove, SAM's delete user option has an option to "Delete all Users files" when you delete the user via SAM.

[James R. Ferguson]

Hi Peter:

'find' is designed for recursive searches of directories. Thus for very large filesystems (i.e. ones with many files), 'find' is a time-consuming process.

To speed up the process, limit 'find' to only those directories you need to search and make sure you're not searching a mounted CDROM!

...JRF...

[Peter_17]

I should have stated: "other than by using SAM to delete accounts". Regardless, how does SAM determine which files are owned by a user throughout the system? Does it use `find` as well? Does it look outside of the users home for files? Is there a "quick" way to determine if a user has files outside his/her home directory?


Pete

[A. Clay Stephenson]

Hi Peter,

Since this is a recursive algorithm we need to avaoid multiple scans of the data. If you are deleting the files for more than one user then I can suggest 2 methods:

find . \( -user user1 -o -user user2 ... \)

or if you delete the users first

find . -nouser

This limits you to 1 traversal for multiple users. As James suggested, limit the scope of the finds by specifying a smaller tree.

Food for thought, Clay

[A. Clay Stephenson]

No SAM does nothing magical. There is no way to know who owns files other than to scan the tree. The only thing you could do to make this a little better (and the gains would be small) is to code a c program using ftw(). This would avoid the overheads of the system call to -exec rm {}\; Find itself uses ftw so the gains would be tiny at best.

Clay

[James R. Ferguson]

Hi Peter:

Here's one possible "speed-up". Consider using:

# userdel -r username

for each "username" you need to remove. This will remove only the user's $HOME directory, and subordinate files, cleanup /etc/group and /etc/passwd and is quite quick.

THEN, remove the unowned files, if any, throughout the filesystems at large:

# find / -nouser -exec rm -i {} \;

This can be scripted in a few lines like:

#!/usr/bin/sh
for USER in him her it
do
userdel -r $USER
done
find / -nouser -exec rm -i {} \;
#.end.

Regards!

...JRF...

[Robin Wakefield]

Pete,

Another thing worth remembering is that with find, it's a lot more efficient to pipe through xargs, rather than use -exec. xargs will process as many arguments as it can within one process, limited by the command line length limit. -exec is one process per file.

Robin.

[Robin Wakefield]

Peter,

To prove my point, I ran the following two commands on one of our OpenMail servers:

> date
> find ./*data* -user 28 -type f -exec ls {} >/dev/null \;
> date
Wed Jul 18 08:47:16 BST 2001
Wed Jul 18 09:34:51 BST 2001

> date
> find ./*data* -user 28 -type f | xargs ls > /dev/null
> date
Wed Jul 18 09:40:25 BST 2001
Wed Jul 18 09:44:29 BST 2001

so -exec took 47 minutes, xargs took 4 minutes!!

Robin

[Wodisch]

Hello Peter,

why not create a list of your files and their owners
with one "find / -print" to a file and then use "awk",
or "perl" or "grep" to find your/their files?
Create the list of files to be removed, check it, and
then remove them (with "xargs", perhaps).
But do the manual check, really!

HTH,
Wodisch

[Bill Hassell]

One thing to keep in mind: ordinary users will not have any files stored in the vast majority of directories. For instance, there is no reason to search through /etc or /dev since they do not allow ordinary users storage permissions. A way to narrow things down is to first identify where user-droppings might exist. On a properly protected HP-UX system, there's only 3 places:

/home/user-name
/var/tmp
/tmp

That's it. However, if your root umask is 000 then there may dozens, perhaps hundreds of mistakes on your system where directories aer wide open, ie 777 permission. There is a common error in HP-UX where /usr/local directories are 777 out of the box...not a good idea at all.

And mountpoints for databases are accidently left as 777 when trying to fix things and then never returned to a safe state (ie, 755). Once the system has been scanned for open directories, then find can be restricted to just those locations, significantly less overhead and time.

[Darrell Allen]

One point about finding nouser files: In a perfect world all files are owned by a user but in my world people sometimes get files on the system without changing ownership. So finding nouser files may lead to deleting some I really don't want to delete.

[James R. Ferguson]

Hi Folks:

I agree with you, Darrell, that you may have a system into which "unowned" files have found their way.

First, one could, obviously, precede the user deletion run with a 'find' of the "nouser" class, accounting for them first.

Second, notice that I used the interactive ('-i') variation of the 'rm'. I personally would want one last change to see what I am removing and confirm my intention.

Thirdly, Robin's point of 'xargs' being faster then the 'exec' is certainly true. The 'exec' causes a new process to be spawned for every file to be removed -- not cheap. However, I would hope that the majority of the files that the user(s) had were handled by 'userdel' in the user's $HOME directory. Thus the number of "nouser" entities would be small and hence the number of 'exec's limited.

Lastly, while I agree with Bill that the permissions on directories should be such that normal user files wouldn't have been deposited, I think I'd still do the brute search just to make sure a door hadn't been left open just long enough for someone to sneak in! ;-)

Regards!

...JRF...