Hi All, I recently encountered files on an overlayfs which returned EIO (Input/output error) for open, stat, and unlink (and presumably other) syscalls. I eventually determined that the files had been redirected and the target removed from the lower level. The behavior can be reproduced as follows: # Create overlay with foo.txt on lower level mkdir -p lower upper work merged touch lower/foo.txt mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=work,metacopy=on none merged # Redirect bar.txt on upper to foo.txt on lower mv merged/foo.txt merged/bar.txt # Remove foo.txt on lower while unmounted umount merged rm lower/foo.txt # open, stat, and unlink on bar.txt now fail with EIO: mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=work,metacopy=on none merged cat merged/bar.txt stat merged/bar.txt rm merged/bar.txt At this point, the only way to recover appears to be unmounting the overlay and removing the file from upper (or updating the overlay.redirect xattr to a valid location). Is that correct? Is this the intended behavior? I didn't see any tests covering it in unionmount-testsuite. If so, perhaps the behavior could be noted in "Changes to underlying filesystems" in Documentation/filesystems/overlayfs.rst? I'd be willing to write a first draft. (I doubt I understand it well enough to get everything right on the first try.) Also, if there is any way this could be made easier to debug, it might be helpful for users, particularly newbies like myself. Perhaps logging bad redirects at KERN_ERR? If that would be too noisy, perhaps only behind a debug module option? Again, if this is acceptable I'd be willing to draft a patch. (Same caveat as above.) Thanks for considering, Kevin