As of a few updates ago ─ no longer than a month, I’d say ─ I’ve begun noticing something weird in the output of df. I suspect it’s a bug of some sorts, but the question is where, because it obviously pertains to /run/user/$(id), which lives on a tmpfs and is probably created by systemd or one of its subsystems.
I have no idea what creates /run/user/1000/doc, and as you can see, the only directory in there is /run/user/1000/doc/by-app, which is empty.
But what’s odd is that both of these directories have unusual permissions ─ they are read-only for the owner ─ as well as the fact that df would throw up an error about that, because to the best of my knowledge, df does not attempt to write to anything.
Except perhaps if you count updating the atime as a write. And such is possible, but then I’d need to know what process is mounting /run/user/1000, and where this is defined, so that I can add noatime to the mount options, or change the permissions so that the owner ─ i.e. user 1000, being me ─ has write permission to the /run/user/1000/doc and /run/user/1000/doc/by-app directories (which is probably how it should be).
For what it’s worth ─ and as expected ─ the error message does not appear when df is executed as root.
Related to flatpak, but even tho i remove everything related to it right after install, i still get that Operation not permitted thing even in unstable branch.
Even if i remove the ~/.local/share/flatpak/db and reboot, i still get that …
I have some stuff in that area like gvfs and such that isnt used.
What does use that extensively is PSD (profile-sync-daemon) so any profiles of any browsers are gettings mounted through tmpfs, etc.
(just some side info )
Well, I’m not using any FlatPaks ─ nor Snaps or AppImages for that matter ─ but FlatPak was installed, indeed. I’ve removed it now and masked (only) one of its systemd components ─ the other components were reported by systemctl as “not found”, even though they were installed ─ but the problem still persists.
It’s not a big deal for me, really, but it’s a beauty flaw nevertheless, so I’m reporting it.
But I have never used flatpak, and I’ve deleted ~/.local/share/flatpak. So there can’t be any leftovers in my $HOME.
Yes, that is correct. The root account does not get that message. But then again, root has write access everywhere, and that /run/user/1000/doc directory has 500 permissions. In other words, it’s read-only for the owner.
Well one way or another you ended up with that directory/link/mount thing in your home.
Removing it now should fix your problem but you need to reboot.
If you have and you still have the issue then its something else. Maybe check
stat -f /run/user/1000/doc
And apparently its statfs that df is trying to use…
I’m pretty sure I had pruned the flatpak stuff from my home directory, but something has obviously recreated it there.
The stuff under /var/lib is also weird, because that should have been deleted when I uninstalled flatpak. And flatpak-system-helper.service helper has been masked, so I have no idea what could be responsible.