# find /proc -group root -print > /dev/null & [1] 10966 # find: /proc/tty/driver: Permission denied find: /proc/1/task/1/fd: Permission denied find: /proc/2/task/2/fd: Permission denied . . . find: /proc/8456/task/8456/fd: Permission denied find: /proc/10634/task/10634/fd: Permission denied find: /proc/10966/task/10966/fd/4: No such file or directory [1]+ Exit 1 find /proc -group root -print >/dev/nullNote that the last error message from 'find', with the error you mention (no such...) is for .../task/10966/... which is the PID of the backgrounded 'find'. Also, FYI, all the 'permission denied' messages are for currently running processes that I don't own.
The error msg line gets a new "N" in the path because there's a new PID generated each time you run the command.
The '.../fd/' directory contains the file descriptor numbers for any open files, so 'find' is opening a couple of files (the directory from which it will begin searching is one, don't know what the other might be). This creates a couple of new 'fd' values (3, 4), since stdin, stdout and stderr (0, 1, 2) are already open. 'find' then presumably (this is a guess, I'm not familiar with the code) reads the full directory listing (recursively), closes the discriptor (4), then does a 'stat' on each file, for additional information. But, since the fd has been closed, it no longer exists and can't be stat'd, causing the error.
Bob Vladimir Zolotykh wrote:
Just out of curiosity, why sudo find /proc -group backup -print always terminates with find: /proc/N/fd/4: No such file or directory where N is always a new number ? [Sarge, GNU/Linux]