21

When reviewing my daily logwatch report, I noticed a new df error this morning. I noticed the unusual error at the top of the df listing...

~$ df (when run manually from my own account)
df: /run/user/1000/doc: Operation not permitted

or

(when run via root in the daily logwatch report)
df: /root/.cache/doc: Operation not permitted

Thedoc directory appears in the root /root/.cache/ folder (which I've since deleted), and in my own user account /run/user/1000/ folder (or in any /run/user/* directory after log in).

How can I find out why df has this error?

Update #1:

Note that when I do ls -al /run/user/1000 I get the following, and the point to note is that the doc directory has an odd date. Where might this directory come from?

drwx------ 13 xxxxxxxxxxx xxxxxxxxxxx  380 Apr 16 10:07 .
drwxr-xr-x  4 root        root          80 Apr 16 09:56 ..
srw-rw-rw-  1 xxxxxxxxxxx xxxxxxxxxxx    0 Apr 16 09:56 bus
drwx------  3 xxxxxxxxxxx xxxxxxxxxxx   60 Apr 16 09:56 dbus-1
drwx------  2 xxxxxxxxxxx xxxxxxxxxxx   60 Apr 16 10:14 dconf
dr-x------  2 xxxxxxxxxxx xxxxxxxxxxx    0 Dec 31  1969 doc
drwx--x--x  2 xxxxxxxxxxx xxxxxxxxxxx   60 Apr 16 09:56 gdm
prw-rw-r--  1 xxxxxxxxxxx xxxxxxxxxxx    0 Apr 16 09:56 gnome-session-leader-fifo
drwx------  3 xxxxxxxxxxx xxxxxxxxxxx   60 Apr 16 09:56 gnome-shell
drwx------  2 xxxxxxxxxxx xxxxxxxxxxx  140 Apr 16 09:56 gnupg
dr-x------  2 xxxxxxxxxxx xxxxxxxxxxx    0 Apr 16 10:06 gvfs
drwx------  2 xxxxxxxxxxx xxxxxxxxxxx   40 Apr 16 09:56 gvfs-burn
-rw-------  1 xxxxxxxxxxx xxxxxxxxxxx 1046 Apr 16 10:06 ICEauthority
drwx------  2 xxxxxxxxxxx xxxxxxxxxxx  100 Apr 16 10:06 keyring
srw-rw-rw-  1 xxxxxxxxxxx xxxxxxxxxxx    0 Apr 16 09:56 pk-debconf-socket
drwx------  2 xxxxxxxxxxx xxxxxxxxxxx   80 Apr 16 09:59 pulse
srw-rw-rw-  1 xxxxxxxxxxx xxxxxxxxxxx    0 Apr 16 09:56 snapd-session-agent.socket
drwxr-xr-x  3 xxxxxxxxxxx xxxxxxxxxxx  100 Apr 16 09:56 systemd
-rw-------  1 xxxxxxxxxxx xxxxxxxxxxx    0 Apr 16 09:57 update-notifier.pid

Update #2:

Interesting enough, I have a second laptop which is exactly like my primary laptop, and the /run/user/1000/doc/ directory is there also, with the same weird date, but df works fine there without error.

On my primary laptop, if I run sudo df there are no errors.

Both laptops are running 19.10, with the same -46 kernel, and the same version 8.30 of df.

Update #3:

Problem still exists in 20.04.

Update #4:

Problem still exists in 20.10.

Improve this question
14
  • Is the immutable bit set for these directories? What does lsattr -R /root/.cache/doc (run as root-user) give?
    – mook765
    Apr 16, 2020 at 15:17
  • Strange, the file attributes cannot be read. Which file system do you use?
    – mook765
    Apr 16, 2020 at 15:32
  • @mook765 ext4...
    – heynnema
    Apr 16, 2020 at 15:32
  • Sorry, out of ideas for the moment. Maybe this answer is helpful to find out when the directories have been created.
    – mook765
    Apr 16, 2020 at 15:37
  • Here another link that might be interesting for you.
    – mook765
    Apr 16, 2020 at 15:46

4 Answers 4

Reset to default
9

On my machine, which doesn't need any of these services, I did not have flatpak installed, but the problem could be solved by doing sudo apt remove xdg-desktop-portal and rebooting.

Improve this answer
8

The issue has been reported to Flatpak team, see

https://github.com/flatpak/xdg-desktop-portal/issues/512

Improve this answer
1
7

As far as I can tell this is a flatpak bug, see:

$ systemctl --user status xdg-document-portal.service
● xdg-document-portal.service - flatpak document portal service
     Loaded: loaded (/usr/lib/systemd/user/xdg-document-portal.service; static; vendor preset: disabled)
     Active: active (running) since Thu 2020-06-04 11:44:00 IDT; 13min ago
   Main PID: 19879 (xdg-document-po)
      Tasks: 7 (limit: 16579)
     Memory: 2.7M
        CPU: 20ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/xdg-document-portal.service
             ├─19879 /usr/libexec/xdg-document-portal
             └─19887 fusermount -o rw,nosuid,nodev,fsname=portal,auto_unmount,subtype=portal -- /run/user/1000/doc

$ df -h > /dev/null
df: /run/user/1000/doc: Operation not permitted

$ systemctl --user stop xdg-document-portal.service
$ df -h > /dev/null
$

So flatpak fusermounts to allow exporting files to sandboxed applications: Flatpak Command Reference - Flatpak documentation

Improve this answer
1
  • +1 Thanks for the research. The problem has returned, and now two directories give the error... /root/.cache/doc: Operation not permitted (when in root), and /run/user/1000/doc: Operation not permitted. I look at snap list and flatpak list and I don't see anything that might be related to the df command. What am I missing? Are you aware of a fix?
    – heynnema
    Jun 4, 2020 at 14:41
4

This is regarded as a bug in gnulib, which has been fixed in this commit (June 2021). Referenced discussions:

EDIT: As said in comments by braoult, this "fix" does not affect df -a, and an explicit df /run/user/1000/doc has the same issue. The fix should really be in xdg-desktop-portal. The bug report: https://github.com/flatpak/xdg-desktop-portal/issues/553

Improve this answer
5
  • Thanks for the update!
    – heynnema
    Jul 26, 2021 at 13:40
  • I don't think hiding the issue is a good way to go. Running strace df -a shows the error: statfs("/run/user/1000/doc", 0x7ffe92bdd160) = -1 EPERM (Operation not permitted). This filesystem should be fixed (implement statfs()), not the tools which try to access it.
    – braoult
    May 17, 2022 at 9:21
  • @braoult Perhaps, but I think that this is debatable, as the issue is not specific to the fuse.portal filesystem. You can see in the commit that fuse.portal has been added to some list of blacklisted filesystems.
    – vinc17
    May 17, 2022 at 15:02
  • 1
    @vinc17, not exactly. The command I discussed was df -a, unrelated to the patch above. Only one filesystem fails here : /run/user/1000/doc. All others (including those in the list of blacklisted FS) have no issue, and implement statfs(). Trying to blacklist does not solve the issue at all, it allows to hide some "useless" filesystems to the user, for some commands with some options (like df without -a), not for the multitude of programs in the wild which expect a working statfs() on a mounted filesystem.
    – braoult
    May 17, 2022 at 16:30
  • @braoult Thanks for the details. I've completed my answer. However, I think that the change in gnulib is still useful to avoid a spurious line in df output once this is fixed in xdg-desktop-portal.
    – vinc17
    May 18, 2022 at 1:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.