/run/user/1000/doc/ has hundreds of media files left there over months by flatpak apps

[Randomname123]

I was shocked to find that there are almost 200GB of folders/files in /run/user/1000/doc/ and some of the files were left there for a long time. One folder even has my entire desktop copied there. I have no idea how that happened.

I understood that these folders are there because flatpak is sandboxed and so has to copy files here to access them but it’s not cleaning them after that on reboots. Apparently that is the job of plasma-xdg-desktop-portal-kde.service

But this is the output of: journalctl --user -u plasma-xdg-desktop-portal-kde.service -f

Mar 06 09:03:41 username-allseries xdg-desktop-portal-kde[13040]: Failed to register with host portal QDBusError(“org.freedesktop.portal.Error.Failed”, “Could not register app ID: Connection already associated with an application ID”)

How do I fix this not initializing properly? please guide me as to what info you need to help diagnose this issue, but i’m wondering if this is happening to all Manjaro/KDE users but we’re not aware of it.

Please run this command to see for yourself (this checks the total space of this folder):
du -sh /run/user/1000/doc/

This was my output and I was shocked:

185G /run/user/1000/doc/

My system:
Operating System: Manjaro Linux
KDE Plasma Version: 6.5.5
KDE Frameworks Version: 6.23.0
Qt Version: 6.10.2
Kernel Version: 6.18.12-1-MANJARO (64-bit)
Graphics Platform: Wayland

[BG405]

Sounds really odd; just checked mine:

[brian@BG-IdeaPad ~] $  du -sh /run/user/1000/doc/
0       /run/user/1000/doc/

/run/ is temporary (or should be). Maybe your full inxi -zv8 will help; e.g. are you saying this is still the case after reboot?

I’d wait for someone with Flatpak experience, though.

Edit: It appears empty on mine as I don’t have any FlatPak programs installed on this system …

[linux-aarhus]

The /run folder is a fixed folder - but anything below is volatile and is recreated at run time (at least that is how I remember it).

You should be able to verify this by booting a live ISO.

Then mount your root partition and inspect the content of the <mountpoint>/run folder.

 $ stat /run/user/1000/doc
  File: /run/user/1000/doc
  Size: 0               Blocks: 0          IO Block: 4096   directory
Device: 0,67    Inode: 1           Links: 2
Access: (0500/dr-x------)  Uid: ( 1000/      fh)   Gid: ( 1000/      fh)
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: -

 $ ls -l /run/user/1000/doc
total 0
dr-x------ 2 fh fh 0  1 jan  1970 by-app

The ‘files’ you see is links pointing to files - not the files themselves.

[BG405]

I’ve added the missing / to my previous post.

[qruqs]

@Randomname123

/run/user/1000/doc/

I have a few flatpak apps, but mine is still empty:

$ du -sh /run/user/1000/doc/
0       /run/user/1000/doc/

For the fun of it, let’s try starting some … … … QGIS and MyPaint started:

$ du -sh /run/user/1000/doc/
0       /run/user/1000/doc/

It seems to me that not all flatpak apps behave the same, or the ones I use don’t use any resources that need to be in that directory structure.

[Randomname123]

Aarhus san was right. The /run/user/1000/doc folder is just a virtual FUSE filesystem that only references the original file locations on the hard disk but doesn’t actually physically contain them itself. (This is just so that flatpak apps can access them)

du -sh /run/user/1000/doc/ here is measuring the disk space used by the original referenced files in the home folder and not the “virtual files” in this folder.

When I stop the relevant xdg portals the FUSE filesystem disappears:

systemctl --user stop xdg-document-portal
systemctl --user stop plasma-xdg-desktop-portal-kde.service

Running the above two commands disables the portal service related to the flatpaks so now when I run du -sh /run/user/1000/doc/ the new output is 0 /run/user/1000/doc/ and this folder becomes empty, but the original files are not affected.

(If you try this don’t forget to restart both services above again by typing start instead of stop and the folder and files will return again as if nothing happened)

The only way to make the files disappear is to either:

rm -rf ~/.local/share/flatpak/db < this deletes the actual database for all those referenced files

or (this is safer):
mv ~/.local/share/flatpak/db ~/.local/share/flatpak/db.backup < you can restore db.backup if something goes wrong

The only reason to do this is to “clear” the history of all the flatpaks you uninstalled and their accessed files. For 99.97% of people you don’t need to do anything it’s fine.

This whole thing started because I thought it was secretly eating up a huge chunk of my SSD space… (but at least I learnt a few more things about howstuffworks™ on linux)

TL;DR Everything is fine. No need to do anything.

[Just a quick update (08.03.26): after I renamed the db folder to db.backup all the clutter of files and folders that were in /run/user/1000/doc/ are gone now and the system made a new doc folder that is mostly empty. It’s a lot cleaner now and I tested most of my flatpak apps and they’re all working fine. I think it’s safe for me to delete the db.backup now. Just thought i’d mention this for future reference if anyone wants to do the same.]