df fails on /run/user/1000/doc with "Operation not permitted"

[LaurentBonnaud]

Hi,

this is a followup to issue #512 that has become confused by a root/non-root sub-issue. The problem here is that df displays an error message for something that is not an error:

$ df
/bin/df: /run/user/1000/doc: Operation not permitted
Filesystem                          1K-blocks      Used Available Use% Mounted on
tmpfs                                 1624464     31012   1593452   2% /run
[...]

Here are xdg-desktop-portal processes that run on this system (note that there are no processes owned by root contrary to the other issue I mentioned):

$ ps aux | grep xdg
bonnaudl  149811  0.0  0.0  80728  6156 ?        Ssl  09:44   0:00 /usr/libexec/xdg-document-portal
bonnaudl  149814  0.0  0.0  56024  5852 ?        Ssl  09:44   0:00 /usr/libexec/xdg-permission-store
bonnaudl  149834  0.0  0.1 148672 18196 ?        Ssl  09:44   0:00 /usr/libexec/xdg-desktop-portal
bonnaudl  149838  0.0  0.1  95328 20860 ?        Ssl  09:44   0:00 /usr/libexec/xdg-desktop-portal-gtk
bonnaudl  149847  0.0  0.4 301700 73644 ?        Sl   09:44   0:00 /usr/lib/x86_64-linux-gnu/libexec/xdg-desktop-portal-kde

Here is another relevant process:

root      149819  0.0  0.0   4684  2996 ?        Ss   09:44   0:00 fusermount -o rw,nosuid,nodev,fsname=portal,auto_unmount,subtype=portal -- /run/user/1000/doc

Is this problem in xdg-desktop-portal, fuse or df ? I think that at least one of those 3 pieces of software should be modified so that the error message is not displayed.

[Erick555]

Ubuntu is going to fix this in df, you may ask your distro to do the same. Even better report this to coreutils project.

[gh503]

well, I met this issue today on my laptop.

scene:

% df
df: /run/user/1000/doc: 不允许的操作
文件系统             容量  已用  可用 已用% 挂载点
devtmpfs              12G     0   12G    0% /dev
tmpfs                 12G  5.5M   12G    1% /dev/shm
tmpfs                4.7G  2.0M  4.7G    1% /run
/dev/mapper/os-root   69G  760M   65G    2% /
/dev/mapper/os-usr    98G   40G   53G   44% /usr
/dev/sda2            976M  253M  656M   28% /boot
/dev/mapper/os-tmp   9.8G  476M  8.9G    6% /tmp
/dev/sda1            599M   23M  577M    4% /boot/efi
/dev/mapper/os-home   98G   21G   73G   23% /home
/dev/mapper/os-opt    98G  2.9G   91G    4% /opt
/dev/mapper/os-var   591G  100G  461G   18% /var
/dev/loop1            98M   98M     0  100% /var/lib/snapd/snap/core/9993
/dev/loop2           9.2M  9.2M     0  100% /var/lib/snapd/snap/shadowsocks/64
/dev/loop0            98M   98M     0  100% /var/lib/snapd/snap/core/10583
tmpfs                2.4G  224K  2.4G    1% /run/user/1000

software version

% cat /etc/system-release
Fedora release 33 (Thirty Three)
% uname -r
5.11.15-200.fc33.x86_64

I remember i just uninstall and install some packages including pencil via rpm -e and flameshot via software-shop

[johnfreed]

Coreutils has been modified to mask the error message, but the underlying problem remains.

Is this problem in xdg-desktop-portal, fuse or df ? I think that at least one of those 3 pieces of software should be modified so that the error message is not displayed.

It does not appear to be an error in either fuse or df. In fact, both fuse and df work just fine with a similar filesystem, gvfs.

So it appears that xdg-desktop-portal is doing something nonstandard. As it was explained to me (https://bugzilla.redhat.com/show_bug.cgi?id=1913358#c22) "the statfs() syscall, which is used by df" fails when addressing /run/user/1000/doc, while it succeeds in addressing /run/user/1000/gvfs

So now, when you issue the df command by itself, you don't see /run/user/1000/doc at all, but if you try:
$ df /run/user/1000/doc
you get:
df: /run/user/1000/doc: Operation not permitted
as before.

By contrast, when you try:
$ df /run/user/1000/gvfs
you get:

Filesystem     1K-blocks  Used Available Use% Mounted on
gvfsd-fuse             0     0         0    - /run/user/1000/gvfs

as expected.

[gyurmogyuri]

Yes! I have same

[vinc17fr]

As explained in this comment on askubuntu.com, the workaround in df does not affect df -a, where fuse.portal is the only one that issues an error due to the failing statfs system call. So xdg-desktop-portal really needs to be fixed on its side.