I am trying to write a script that fixes the ownership of all files owned by a specific user, after changing the user's UID.

Currently, I run:

chown -Rhc --from=${OLD_UID} ${NEW_UID} /
chown -Rhc --from=:${OLD_UID} :${NEW_UID} /

Where OLD_UID and NEW_UID are the old and new UIDs of the user I have just modified.

This has the desired effect, but always exits with a return code of 1, because of errors like this:

chown: cannot access ‘/proc/1103/task/1103/fd/4’: No such file or directory
chown: cannot access ‘/proc/1103/task/1103/fdinfo/4’: No such file or directory
chown: cannot access ‘/proc/1103/fd/4’: No such file or directory
chown: cannot access ‘/proc/1103/fdinfo/4’: No such file or directory

My theory is that the process finding all files picks up its own process, which then does not exist when chown tries to access it.

I could just throw away the return code from the commands, but I would prefer not to in case I end up ignoring real errors.

Can anyone suggest an alternative approach that will not report false errors?


You could use find, and tell it to not descent into other filesystems (which should prevent it from accessing virtual filesystems like proc, sys, etc):

find / -xdev -uid ${OLD_UID} -execdir chown ${NEW_UID} {} +

This may not be as efficient.

Another way to filter out the virtual files would be to remount the root filesystem somewhere else:

mkdir /tmp/chroot
mount -o .. -t .. /dev/... /tmp/chroot

And run chown on /tmp/chroot.

  • In the case of the second solution, isn't there still /tmp/chroot/dev? Also, is it really safe to mount the same filesystem in two places? – Barmar Dec 12 '14 at 22:38
  • @Barmar indeed, but none of the device files would be owned by a normal user, right? Some systems don't allow it, but some do. So, I don't know. – muru Dec 12 '14 at 22:40
  • Of course, but the objective is to keep it from drilling into the device directory in the first place. – Barmar Dec 12 '14 at 22:43
  • @Barmar One of the objectives is. If it really is important, bind-mounting an empty folder over /tmp/chroot/dev should solve that problem. – muru Dec 12 '14 at 22:44
  • That seems to be the primary objective -- he just wants to prevent the errors when it tries to recurse into subdirectories that disappear while the command is running. – Barmar Dec 12 '14 at 22:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.