Description of problem: While running a recursive restorecon, I found that it can fail with $ restorecon -nvvR / restorecon: Could not set context for /boot/grub2/grubenvl355DR: No such file or directory This is likely because of a well-known "readdir vs read" race condition, where a program does readdir() first, and then goes over the resulting list of files, performing some operation on them. If one of the files gets deleted while that traversal is happening (such as by being a temporary file), the program would get ENOENT. Version-Release number of selected component (if applicable): policycoreutils-3.3-6.el9_0.x86_64 How reproducible: rarely on a real system always using the reproducer below, within ~10 seconds Steps to Reproduce: 0. Have (preferably) multicore (SMP) hardware 1. Open up two terminals 2. In one, run a loop of always-creating files with a wrong context, ie. - mkdir foo; cd foo - while :; do touch a b c; chcon -t etc_t a b c; rm -f a b c; done 3. In the other terminal, run restorecon attempting to correct them, ie. - while restorecon -Rvvn foo/; do :; done Actual results: restorecon sometimes fails on a filesystem using temporary files Expected results: restorecon silently ignores ENOENT for files that were seen in readdir()