On 2/16/19 12:14 PM, Bill Gee wrote:
...After the usermod programs ran, I then did a "find -uid=500" with an exec option to change ownership. Repeat for changing GID. It found a few dozen files that were not in my home directory.
On the server I ran the two "find" commands against the entire file system. It took about half an hour to run. No surprise there as it was finding and changing several hundred thousand files. I ran the uid change in one terminal and the gid change in another. Between the two of them they consumed about 90% on both processor cores.
Hi Bill,
Just sharing some wisdom/experience. Too bad it's after the bulk of your work. :-)
It should not have been consuming much cpu. This is an I/O-based activity.
My guess is you used something like
find -uid=500 -exec chown 1000 {} ;
This will start a chown process for each file, changing only one file at a time. That's a lot of work the system has to do for each file! But you probably know chown (and similar utilities) can take multiple file arguments, and 'find' can help you take advantage grouping many arguments with the '+' operator to -exec:
find -uid=500 -exec chown 1000 {} +
And you could combine the bulk of your I/O work of chgrp-ing for all of your files at the same time by using 'chown 1000:1000'.
You might want to check your symlinks ('find -type l -ls'). You may have changed the ownership of what they point to rather than the link itself, precisely what the chown -h (--no-dereference) option is good for. Don't forget to revisit what the permissions should be on the link targets. Bad things would happen if the user had a symlink to /etc/passwd and/or /etc/shadow in their home directory!
I also like to use -xdev to avoid traversing into any unexpected filesystems. So I end up with:
find /somedir -xdev -uid=500 -exec chown -h newID:newGroup {} +
Hope that helps for the next time or someone else!
[This is off the top of my head, so beware of any mistakes...these commands have significant consequences.]
Best regards,
Chris Schanzle