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
  • 14,308
  • 4
  • 74
  • 117
heynnema
  • 68,647
  • 15
  • 124
  • 180
  • 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](https://stackoverflow.com/a/19569086) is helpful to find out when the directories have been created. – mook765 Apr 16 '20 at 15:37
  • [Here another link](https://serverfault.com/q/324975) 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](https://unix.stackexchange.com/a/162911). – 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
  • 63
  • 1
  • 6
a3nm
  • 423
  • 6
  • 10
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/[email protected]/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
  • 5
  • +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
8

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

Pablo Bianchi
  • 14,308
  • 4
  • 74
  • 117
murashkin17
  • 81
  • 1
  • 1
  • 1
    See also follow-up issue: https://github.com/flatpak/xdg-desktop-portal/issues/553 – a3nm Feb 22 '22 at 16:24
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

vinc17
  • 166
  • 6
  • 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](https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=9a38d499ca16f2f4304992eb1ab0894cd0b478e1) 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