Error message in `df` output ─ bug?

As of a few updates ago ─ no longer than a month, I’d say ─ I’ve begun noticing something weird in the output of df. I suspect it’s a bug of some sorts, but the question is where, because it obviously pertains to /run/user/$(id), which lives on a tmpfs and is probably created by systemd or one of its subsystems.

[06:52:05][aragorn] > df -Th
df: /run/user/1000/doc: Operation not permitted
Filesystem     Type      Size  Used Avail Use% Mounted on
devtmpfs       devtmpfs  7.8G     0  7.8G   0% /dev
tmpfs          tmpfs     7.8G  143M  7.7G   2% /dev/shm
tmpfs          tmpfs     3.2G  9.3M  3.1G   1% /run
tmpfs          tmpfs     4.0M     0  4.0M   0% /sys/fs/cgroup
/dev/sda3      btrfs     1.0G   26M  767M   4% /
/dev/sda4      btrfs      22G  6.5G   15G  31% /usr
tmpfs          tmpfs     7.8G  8.7M  7.8G   1% /tmp
/dev/sda6      btrfs     2.0G  101M  1.7G   6% /opt
/dev/sda9      btrfs     450G  2.8G  446G   1% /home
/dev/sda5      btrfs     512M  3.4M  499M   1% /usr/local
/dev/sda11     btrfs      20G  3.2G   17G  16% /var
/dev/sda8      btrfs     400G   72G  328G  18% /srv
/dev/sda2      ext4      488M   63M  390M  14% /boot
/dev/sda1      vfat      511M  544K  511M   1% /boot/efi
tmpfs          tmpfs     1.6G  132K  1.6G   1% /run/user/1000

[06:52:17][aragorn] > ls -l /run/user/1000/
total 4
srwx------ 1 aragorn aragorn   0 Oct 22 10:44 993e2851f4b9f6f91ec502ed8ee648bb-{87A94AB0-E370-4cde-98D3-ACC110C5967D}
drwx------ 2 aragorn aragorn 120 Oct 22 10:43 akonadi
srw-rw-rw- 1 aragorn aragorn   0 Oct 21 12:00 bus
drwx------ 3 aragorn aragorn  60 Oct 21 12:00 dbus-1
drwx------ 2 aragorn aragorn  60 Oct 21 12:00 dconf
srwx------ 1 aragorn aragorn   0 Oct 23 11:55 discord-ipc-0
dr-x------ 2 aragorn aragorn   0 Jan  1  1970 doc
drwx------ 2 aragorn aragorn 140 Oct 21 12:00 gnupg
srw------- 1 aragorn aragorn   0 Oct 22 10:43 kdeinit5__0
drwx------ 2 aragorn aragorn  60 Oct 23 18:14 keyring
srwx------ 1 aragorn aragorn   0 Oct 21 12:12 kio_http_cache_cleaner
srwx------ 1 aragorn aragorn   0 Oct 22 10:43 klauncherfGaJrL.1.slave-socket
srwx------ 1 aragorn aragorn   0 Oct 21 12:00 klauncherPFOsBY.1.slave-socket
-rw------- 1 aragorn aragorn  81 Oct 22 10:43 KSMserver__0
srwxr-xr-x 1 aragorn aragorn   0 Oct 22 10:43 kwallet5.socket
drwxr-xr-x 2 aragorn aragorn  60 Oct 21 12:00 p11-kit
srw-rw-rw- 1 aragorn aragorn   0 Oct 21 12:00 pipewire-0
-rw-r----- 1 aragorn aragorn   0 Oct 23 18:14 pipewire-0.lock
drwx------ 2 aragorn aragorn 100 Oct 22 10:43 pulse
drwxrwx--x 2 aragorn aragorn  40 Oct 21 17:34 signond
drwxr-xr-x 6 aragorn aragorn 160 Oct 21 12:02 systemd

[06:53:08][aragorn] > ls -l /run/user/1000/doc/
total 0
dr-x------ 2 aragorn aragorn 0 Jan  1  1970 by-app

[06:54:06][aragorn] > ls -l /run/user/1000/doc/by-app/
total 0

[06:54:14][aragorn] >

I have no idea what creates /run/user/1000/doc, and as you can see, the only directory in there is /run/user/1000/doc/by-app, which is empty.

But what’s odd is that both of these directories have unusual permissions ─ they are read-only for the owner ─ as well as the fact that df would throw up an error about that, because to the best of my knowledge, df does not attempt to write to anything.

Except perhaps if you count updating the atime as a write. And such is possible, but then I’d need to know what process is mounting /run/user/1000, and where this is defined, so that I can add noatime to the mount options, or change the permissions so that the owner ─ i.e. user 1000, being me ─ has write permission to the /run/user/1000/doc and /run/user/1000/doc/by-app directories (which is probably how it should be).

For what it’s worth ─ and as expected ─ the error message does not appear when df is executed as root.

1 Like

Seems to have been discussed here

Related to flatpak, but even tho i remove everything related to it right after install, i still get that Operation not permitted thing even in unstable branch.
Even if i remove the ~/.local/share/flatpak/db and reboot, i still get that … :man_shrugging:

1 Like

I have some stuff in that area like gvfs and such that isnt used.
What does use that extensively is PSD (profile-sync-daemon) so any profiles of any browsers are gettings mounted through tmpfs, etc.
(just some side info :wink:)


Well, I’m not using any FlatPaks ─ nor Snaps or AppImages for that matter ─ but FlatPak was installed, indeed. I’ve removed it now and masked (only) one of its systemd components ─ the other components were reported by systemctl as “not found”, even though they were installed ─ but the problem still persists.

It’s not a big deal for me, really, but it’s a beauty flaw nevertheless, so I’m reporting it. :wink:

On my system I had the same output until I removed ~/.local/share/flatpak/db


Well, I’ve deleted the whole of ~/.local/share/flatpak now ─ no need for it anymore because I had already uninstalled flatpak earlier ─ but the bug is still showing up.

Of course, it might be different if I log out and back in, but at the moment I’m too busy. I’ll see whether I can log out in a few minutes, and then I’ll get back to you on that. :wink:

Yup … needed to for me. (well … reboot in my case)

Well, logging out and back in didn’t fix it. Maybe a reboot would, but I’m not going to do that just now.

Either way, it is obviously a bug, and just as obviously ─ as @bogdancovaciu pointed out ─ caused by flatpak. :thinking:

I dont know if its a bug.
Its more like its a fuse mount (in this created because of flatpaks docs and leftovers in your home) … you probably wouldnt see the error using sudo.

But I have never used flatpak, and I’ve deleted ~/.local/share/flatpak. So there can’t be any leftovers in my $HOME.

Yes, that is correct. The root account does not get that message. But then again, root has write access everywhere, and that /run/user/1000/doc directory has 500 permissions. In other words, it’s read-only for the owner.

Well one way or another you ended up with that directory/link/mount thing in your home.
Removing it now should fix your problem but you need to reboot.
If you have and you still have the issue then its something else. Maybe check

stat -f /run/user/1000/doc

And apparently its statfs that df is trying to use…

1 Like
[12:19:40][aragorn] >  stat /run/user/1000/doc
  File: /run/user/1000/doc
  Size: 0               Blocks: 0          IO Block: 4096   directory
Device: 50h/80d Inode: 1           Links: 2
Access: (0500/dr-x------)  Uid: ( 1000/ aragorn)   Gid: ( 1000/ aragorn)
Access: 1970-01-01 01:00:00.000000000 +0100
Modify: 1970-01-01 01:00:00.000000000 +0100
Change: 1970-01-01 01:00:00.000000000 +0100
 Birth: -

[12:21:42][aragorn] >  stat -f /run/user/1000/doc
stat: cannot read file system information for '/run/user/1000/doc': Operation not permitted

That seems to be the expected outcome. As in its the same as your df.
(in my case after rebooting that directory disappeared and was not recreated)

1 Like

Well, I have managed to reboot my system now, and indeed, the issue has been resolved, even though it clearly is a bug, as pointed out by @bogdancovaciu.

I’ll mark one of your posts as the solution, even though it does of course not resolve the problem for those who still have flatpak installed. :man_shrugging:

Still, I appreciate your help in hunting this down and helping me get rid of the error. :beers:

1 Like

I guess I spoke too soon. It’s back… :arrow_down:

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


pacman -Qs flatpak


[10:14:19][aragorn] >  pacman -Qs flatpak

[10:16:57][aragorn] >

However… :arrow_down:

[10:18:42][aragorn] >  locate flatpak

I’m pretty sure I had pruned the flatpak stuff from my home directory, but something has obviously recreated it there.

The stuff under /var/lib is also weird, because that should have been deleted when I uninstalled flatpak. And flatpak-system-helper.service helper has been masked, so I have no idea what could be responsible. :astonished: