On Jan 21, 2023, at 18:55, Tom Horsley <horsley1953@xxxxxxxxx> wrote: > > On Sat, 21 Jan 2023 23:31:43 -0000 > old sixpack13 wrote: > >> rm -rfv /root/.cache/doc >> rm: cannot remove '/root/.cache/doc/by-app': Operation not permitted > > That is (if I recall) an annoying fuse or special device file of some > kind created by some annoying xdg or gnome something that I spent a long > time figuring out how to disable specifically because it caused rsync > errors in backups making me think there was a backup problem. Whatever > purpose it serves is something I don't use because I've never had > a problem after eradicating it. I've currently got all these "user" > services masked, I think it was one of them (probably the document > portal thing). > > flatpak-oci-authenticator.service > flatpak-portal.service > flatpak-session-helper.service > tracker-xdg-portal-3.service > xdg-desktop-portal-gtk.service > xdg-desktop-portal.service > xdg-document-portal.service The existence of a /root/.cache/doc fuse mount is because the xdg-document-portal service ran (maybe because a flatpak was run as root?) and there was no XDG_RUNTIME_DIR (which would be /run/user/0/ when a full session is run). In the absence of a runtime dir, the portals use XDG_CACHE_HOME, which is ~/.cache. Obviously, no one should be logging in with a full dbus session with root, so it is weird that root got this mountpoint. It isn’t an SELinux issue, you are just trying to delete a mountpoint with rm, which is not permitted. If it happens again, check /proc/self/mounts to see if it is a mountpoint. This isn’t something special about fuse mounts, if you tried to delete the directory where a local or remote filesystem was mounted, it would generate the same error, even as root. Turning off and disabling the xdg-desktop services for all users will cause more problems down the road if you want to have a sandboxed flatpak app running as a normal user. Don’t recommend it. You should figure out why the root user was trying to set up a flatpak sandbox or whatever else is triggering the desktop portal as root. A reboot will fix it too, since the XDG services aren’t automatically started for root. -- Jonathan Billings _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
