On Sun, 2021-05-02 at 18:05 +1000, Michael D. Setzer II via users wrote:
Ran the following command in / to see what it finds. find . -xtype l >/badlinks
Summary of results of broken links by top directory /etc 15 /home 17 /proc 170 /root 2 /run 145 /usr 325 674
Not an awful lot, but wonder if they should be fixed or just left alone?
On a whim, I tried your command on my CentOS 7 (clean install) system, only these five lines turned up:
find: ‘./proc/1853/task/1853/fd/5’: No such file or directory find: ‘./proc/1853/task/1853/fdinfo/5’: No such file or directory find: ‘./proc/1853/fd/6’: No such file or directory find: ‘./proc/1853/fdinfo/6’: No such file or directory find: ‘./run/user/1000/gvfs’: Permission denied
So, faring better than your discovery.
There is no /proc/1853 anything. So was that a broken link pointing to there, or was it finding something from there, that's now disappeared?
If I do (still as the root user): ll /run/user/1000/
ls: cannot access /run/user/1000/gvfs: Permission denied total 0 drwx------. 2 tim tim 60 May 2 21:25 dconf d?????????? ? ? ? ? ? gvfs drwx------. 2 tim tim 100 May 2 16:25 keyring drwx------. 2 tim tim 80 May 2 16:25 pulse
Not sure if root oughtn't to be able to see gvfs, or that's just some weird anomaly about how virtual file systems work.
Then, as myself, doing: ll /run/user/1000/
total 0 drwx------. 2 tim tim 60 May 2 21:29 dconf dr-x------. 2 tim tim 0 May 2 16:25 gvfs drwx------. 2 tim tim 100 May 2 16:25 keyring drwx------. 2 tim tim 80 May 2 16:25 pulse
I thought root couldn't be stopped from viewing user's files.