df: /run/user/1000/doc: Operation not permitted

Bug #1905623 reported by Julian Andres Klode
38
This bug affects 7 people
Affects Status Importance Assigned to Milestone
coreutils (Ubuntu)
Fix Released
Undecided
Unassigned
xdg-desktop-portal (Ubuntu)
Triaged
Low
Unassigned

Bug Description

/run/user/1000/doc is a fuse.portal mount point, but statfs() return EPERM, hence df produces an error message. Maybe statfs() is not implemented, but it would be good to quieten this down (df even does not allow me to ignore it, probably because it looks at statfs to find out fs type, so my fs type ignoring doesn't work).

Changed in xdg-desktop-portal (Ubuntu):
importance: Undecided → Low
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks, that's being discussed upstream on https://github.com/flatpak/xdg-desktop-portal/issues/512

Changed in xdg-desktop-portal (Ubuntu):
status: New → Triaged
Revision history for this message
Ryan Beisner (1chb1n) wrote :

The upstream bug is closed as working-as-designed, but this is impactful to anything that expects ```df``` to exit 0 as a non-root user.

ex.

me@here:~$ df -h
df: /run/user/1000/doc: Operation not permitted
Filesystem Size Used Avail Use% Mounted on
tmpfs 3.1G 4.6M 3.1G 1% /run
/dev/mapper/vgubuntu-root 914G 184G 684G 22% /
tmpfs 16G 810M 15G 6% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 4.0M 0 4.0M 0% /sys/fs/cgroup
/dev/nvme0n1p2 705M 218M 436M 34% /boot
/dev/nvme0n1p1 511M 7.8M 504M 2% /boot/efi
tmpfs 3.1G 192K 3.1G 1% /run/user/1000
me@here:~$ echo $?
1

me@here:~$ sudo df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 3.1G 4.6M 3.1G 1% /run
/dev/mapper/vgubuntu-root 914G 184G 684G 22% /
tmpfs 16G 808M 15G 6% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 4.0M 0 4.0M 0% /sys/fs/cgroup
/dev/nvme0n1p2 705M 218M 436M 34% /boot
/dev/nvme0n1p1 511M 7.8M 504M 2% /boot/efi
tmpfs 3.1G 192K 3.1G 1% /run/user/1000
me@here:~$ echo $?
0

me@here:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.10
Release: 20.10
Codename: groovy

me@here:~$ uname -a
Linux p100 5.8.0-32-generic #34-Ubuntu SMP Fri Nov 27 15:10:41 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Revision history for this message
Ryan Beisner (1chb1n) wrote :
Revision history for this message
Gordon Lack (gordon-lack) wrote :

>> Thanks, that's being discussed upstream on https://github.com/flatpak/xdg-desktop-portal/issues/512

No, it's not, as that issue has been closed.

Note that I'm seeing this WITHOUT having flatpak installed.

Revision history for this message
Jalon Funk (francescohickle15) wrote :

You can silence this with "df -x fuse.portal"

xdg-desktop-portal isn't tied to flatpak.

Revision history for this message
Gordon Lack (gordon-lack) wrote :

>> You can silence this with "df -x fuse.portal"

I can, but that's not the point.

Whatever is putting the mountpoint there (it's not my choice) should be putting it there in such a way that this does not happen. I *own* the mountpoint directory and file-system. Why should I get an EPERM error that I cannot remove?

Revision history for this message
Jalon Funk (francescohickle15) wrote :

I was referring to Julian comment which stated df can't ignore this.

If you don't want to this fuse fs to be created then either remove xdg-desktop-portal package or mask xdg-document-portal.service with:

systemctl --user mask xdg-document-portal.service

Revision history for this message
Gordon Lack (gordon-lack) wrote :

> If you don't want to this fuse fs to be created

I probably don't, but have no idea want it actually does.

> then either remove xdg-desktop-portal package or mask xdg-document-portal.service with:

Thanks. The masking worked fine.

Revision history for this message
Julian Andres Klode (juliank) wrote :

> I probably don't, but have no idea want it actually does.

It provides safe access to files on your disk to snaps or flatpaks.

> You can silence this with "df -x fuse.portal"

Odd, when I tried it didn't work for me, maybe I made a typo.

Added a task for coreutils - we should ignore fuse.portal in any case, regardless of whether the portal code gets fixed or not, because it's not a real file system that has an actual size.

Changed in coreutils (Ubuntu):
status: New → In Progress
Revision history for this message
Julian Andres Klode (juliank) wrote :

Just to note, a huge number of other file systems don't show:

$ grep fuse /proc/mounts
fusectl /sys/fs/fuse/connections fusectl rw,nosuid,nodev,noexec,relatime 0 0
https://sd2dav.1und1.de/ /media/jak/smartdrive fuse rw,nosuid,nodev,noexec,relatime,user_id=1000,group_id=1000,allow_other,max_read=16384 0 0
gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
portal /run/user/1000/doc fuse.portal rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
keybase-redirector /keybase fuse ro,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other 0 0
/dev/fuse /run/user/1000/keybase/kbfs fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
$ /usr/bin/df -T | grep fuse
/usr/bin/df: /run/user/1000/doc: Operation not permitted
https://sd2dav.1und1.de/ fuse 1333333332 800000000 533333332 61% /media/jak/smartdrive
/dev/fuse fuse 262144000 1 262144000 1% /run/user/1000/keybase/kbfs

Looking at some of them:

$ stat -f /keybase/
  File: "/keybase/"
    ID: 0 Namelen: 0 Type: fuseblk
Block size: 0 Fundamental block size: 0
Blocks: Total: 0 Free: 0 Available: 0
Inodes: Total: 0 Free: 0

$ stat -f /run/user/1000/gvfs
  File: "/run/user/1000/gvfs"
    ID: 0 Namelen: 1024 Type: fuseblk
Block size: 4096 Fundamental block size: 4096
Blocks: Total: 0 Free: 0 Available: 0
Inodes: Total: 0 Free: 0

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package coreutils - 8.32-4ubuntu2

---------------
coreutils (8.32-4ubuntu2) hirsute; urgency=medium

  * d/p/treat-devtmpfs-and-squashfs-as-dummy-filesystems.patch:
    - Extend default filesystem exlusion to fuse.portal (LP: #1905623)

 -- Julian Andres Klode <email address hidden> Sat, 05 Dec 2020 21:55:44 +0100

Changed in coreutils (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
Kamil Dudka (kdudka) wrote :

Has gnulib upstream been notified about the fix for this bug?

... or about the original treat-devtmpfs-and-squashfs-as-dummy-filesystems.patch that the fix was applied to?

https://launchpadlibrarian.net/510003931/coreutils_8.32-4ubuntu1_8.32-4ubuntu2.diff.gz

Revision history for this message
walkerstreet (dbonner) wrote :

Hi Julian and Kamil,
I tried to notify the gnulib upstream developers of this fix by creating a pull request in the github mirror (https://github.com/coreutils/gnulib/pull/11). I don't know how to create a pull request in the original git repository (git://git.sv.gnu.org/gnulib.git). I'm still learning. I hope that the developers are able to see my pull request, even though it is in the github mirror, not the original repository.
All the best,
Daniel

Revision history for this message
walkerstreet (dbonner) wrote :

I just read about the correct way to report a bug or fix to the gnulib developers. I have emailed them as below:
Date: Sat, 13 Feb 2021 at 12:40
Subject: Suggested fix to mountlist.c: Define fuse.portal, devtmpfs and squashfs mounts as dummy
To: <email address hidden>
Cc: <email address hidden>
Hi gnulib developers,
At present many gnulib users encounter this error:
Running 'df' as user (not root) causes results in output that includes
this error message:
"df: /run/user/1000/doc: Operation not permitted"
I would like to pass on to you a suggested fix:

@@ -164,7 +164,10 @@
 #define ME_DUMMY_0(Fs_name, Fs_type) \
   (strcmp (Fs_type, "autofs") == 0 \
+ || strcmp (Fs_type, "devtmpfs") == 0 \
+ || strcmp (Fs_type, "fuse.portal") == 0 \
    || strcmp (Fs_type, "proc") == 0 \
+ || strcmp (Fs_type, "squashfs") == 0 \
    || strcmp (Fs_type, "subfs") == 0 \
    /* for Linux 2.6/3.x */ \
    || strcmp (Fs_type, "debugfs") == 0 \

Julian Klode, from Ubuntu, deserves credit for this suggested fix. He
published a patch that has been included in the Ubuntu Hirsute 21.04
package: coreutils 8.32-4ubuntu2. See

    https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-portal/+bug/19056232.
    https://launchpadlibrarian.net/510003931/coreutils_8.32-4ubuntu1_8.32-4ubuntu2.diff.gz
    I have cc'ed Julian in this email.
    The patch addresses a problem that particularly affects gnulib users
    with fuse.portal mounts, such as users who have installed Flatpak.
    This is a significant problem for users who depend on df not returning
    an error exit code in their scripts. Julian's bug report said:
    "/run/user/1000/doc is a fuse.portal mount point, but statfs() return
    EPERM, hence df produces an error message. Maybe statfs() is not
    implemented, but it would be good to quieten this down (df even does
    not allow me to ignore it, probably because it looks at statfs to find
    out fs type, so my fs type ignoring doesn't work)."
    This problem has also been reported on Fedora 32 here:
    flatpak/xdg-desktop-portal#512
    Kind regards,
    Daniel

Revision history for this message
walkerstreet (dbonner) wrote :

I formatted it as follows:
@@ -164,7 +164,10 @@
 #define ME_DUMMY_0(Fs_name, Fs_type) \
   (strcmp (Fs_type, "autofs") == 0 \
+ || strcmp (Fs_type, "devtmpfs") == 0 \
+ || strcmp (Fs_type, "fuse.portal") == 0 \
  || strcmp (Fs_type, "proc") == 0 \
+ || strcmp (Fs_type, "squashfs") == 0 \
  || strcmp (Fs_type, "subfs") == 0 \
  /* for Linux 2.6/3.x */ \
  || strcmp (Fs_type, "debugfs") == 0 \

Revision history for this message
Kamil Dudka (kdudka) wrote :

Daniel, thank you for submitting the patch upstream!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.