23

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.

Pablo Bianchi
  • 17,552
heynnema
  • 73,937
  • Is the immutable bit set for these directories? What does lsattr -R /root/.cache/doc (run as root-user) give? – mook765 Apr 16 '20 at 15:17
  • Strange, the file attributes cannot be read. Which file system do you use? – mook765 Apr 16 '20 at 15:32
  • @mook765 ext4... – heynnema Apr 16 '20 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 '20 at 15:37
  • Here another link that might be interesting for you. – mook765 Apr 16 '20 at 15:46
  • @mook765 Thanks for your help. Please note my updated "Update #1" where I find this strange "doc" directory with an odd creation date. – heynnema Apr 16 '20 at 17:22
  • I don't think that we see posix permissions for files in /run/user/1000 since it's mounted as tmpfs. Another useful link. – mook765 Apr 16 '20 at 17:42
  • Back to mook765's request, please run lsattr -d .cache/doc and if the i attribute is set, remove it with sudo chattr -i .cache/doc Then you should be able to remove the dir. – ubfan1 Apr 17 '20 at 01:24
  • @ubfan1 Thanks for the help. Actually there are doc directories in two places... /root/.cache/doc (and I've been able to delete that), and a 2nd one in /run/user/1000/doc... and this directory gets recreated on any user login... and with the weird date. So even if I did delete it, it would come back next login. The lsattr command errors with "lsattr: Inappropriate ioctl for device While reading flags on doc". My second machine has none of these problems, and df works fine there. – heynnema Apr 17 '20 at 02:30
  • Check which process has it open(?) with lsof, then ps to further identify the process. – ubfan1 Apr 17 '20 at 15:47
  • @ubfan1 lsof doesn't show that any active process has it open. The /run/user/1000/doc/ and its sub-dir seem to get created at user login. My second machine does the same thing, with the same "Dec 31 1969" date, and df works fine there. On the primary machine, a sudo df works fine. Leads me to believe that there's a permissions problem somewhere. – heynnema Apr 17 '20 at 16:05
  • @ubfan1 Interesting enough, I installed dfc, a colorized version of df, and it throws the same error. – heynnema Apr 17 '20 at 16:13
  • @heynnema As I pointed out, this are not posix permissions what you see. The permissions for files and directories in /run/user/1000 are dictated by systemd, that's why you can't delete doc, even as root-user. The question is which process creates the directory during login. – mook765 Apr 18 '20 at 09:28
  • @mook765 Yes, that's the $64,000 question. How does /run/user/1000 get populated at login time? Where does doc/ come from? There's a gvfs dir there that doesn't seem to throw any errors (but it's an empty dir). And why does df error on my primary system, but not my backup system? Riddles. – heynnema Apr 18 '20 at 15:46

4 Answers4

11

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. Or do systemctl --user stop xdg-document-portal.service without reboot.

Jackfritt
  • 83
  • 1
  • 6
a3nm
  • 473
8

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

Dani_l
  • 181
  • +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 04 '20 at 14:41
7

The issue has been reported to Flatpak team, then follow up by this issue.

Pablo Bianchi
  • 17,552
murashkin17
  • 71
  • 1
    See also follow-up issue: https://github.com/flatpak/xdg-desktop-portal/issues/553 – a3nm Feb 22 '22 at 16:24
5

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

vinc17
  • 196
  • Thanks for the update! – heynnema Jul 26 '21 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 '22 at 09: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 '22 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 '22 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 '22 at 01:19