I know all about

... but I'm getting tired of doing that all the time. Anytime my system seems sluggish, the above is the first thing I do. It always fixes things right up, even if "top" shows that gvfs-metadata is only using 2 or 3% of the CPU (sometimes it goes much higher).

So how do I permanently get rid of this? I doesn't appear to do anything useful. You can apparently kill it any time you want, remove it's directory willy nilly, and there are no negative effects. Only positive effects. You see people reporting problems with this turd software all over the internet. I've read it is a part of Gnome desktop. I don't use Gnome, I use Xfce. I've read it's a part of Nautilus. I don't use Nautilus, I use Thunar. You'd think with all the complaints about it over the years, whoever maintains it would fix the stupid thing. But apparently not. So how do I permanently strangle the little beast so my system can have some peace? I don't mind changing file managers if that would help. I don't really want to give up Xfce though, because I really like that desktop. But I might be willing to give up on Xfce it that would positively get rid of this gvfs-metadata junk.

Its not running at all on my system LM17 with KDE.

Only process running on KDE is gvfsd . Start htop and search for gvfsd,
killing gvfsd may kill it , it could crash the desktop if anything is using
the metadata

Hi there,

make it an hourly cron job. ;-)

No, seriously: I know the problem, too, and I'm experiencing it occasionally with Linux Mint's Mate desktop (which is quasi Gnome) and its file manager Caja (which is quasi Nautilus). And I agree it's a nuisance.

However, I don't know a real solution; the main reason I'm writing this is to have a handle to find this thread again - just in case someone really comes up with a good fix.

It definitely does, sometimes over 50%. But it's not just the high CPU usage; it's also the sluggishness of the file manager. Even if, as you say, the gvfs-metadata process uses "only" 2..3% CPU, Caja sometimes takes a few seconds until it displays the contents of a directory after you navigate into it. And that's annoying, too.

[X] Doc CPU

Don't have this issue (gnome 3), but I regularly have to killall firefox ... :shrug:

For those searching for it and not finding it, that could be because you cut-n-pasted my typo above. Or maybe it's really not running on your system. On my LinuxMint13Xfce system, it is there (except it takes a while to get restarted after I kill it).

The process is gvfsd-metadata, not gvfs-metadata

Many reports I've read (probably all copied from one original speculation, knowing how the internet works!) say that its data store gets corrupted, thus sending it into an infinite loop. If that is actually the case, it is managing to get its data store corrupted quite routinely, and is poorly written in that it cannot detect the corruption and keep itself out of an infinite loop.

I have no idea what it does, and I haven't noticed any problems with it, but I was wondering if it has any relationship to the automounting of my phone as an mtp device when I plug it in. The last line below did not appear until I plugged in my phone.

I too have it present, but have never had it pop up as a problem child - Fedora 20 currently. I (almost) never connect my phone.

I'll have to do some research on my system to determine when it becomes a problem. It's not always a problem. Could be that it kicks in and starts acting up when I plug in my external USB hard drive or my USB camera memory card reader. That's about the only automount stuff that I do. I guess I do insert a CD/DVD occassionally. I have noticed that CD's/DVD's do not always automount. They do most of the time, probably 90% of the time, but sometimes it fails and I have to open the drawer and re-close it. Hmmm, I wonder if that occassional failed automount could be the trigger? I had never thought about that. I'll try to keep closer tabs on what I have done right before it starts acting up. Thanks for bouncing around ideas and giving me something to think about and test.

Resurrecting this old thread to add relevant information which inexplicably cannot be found anywhere. Hope it helps people to lift the undeserved shroud of mystery from gvfs-metadata dir.

As it happens, gvfs DOES have tools for handling its metadata files, for 10 years already. The only problem, they do not get installed by default build.
https://gitlab.gnome.org/GNOME/gvfs/...e98854fa84deb5

To get the tools, one can recompile distro's gvfs package and then, from the build directory, subdirectory metadata/.libs copy the files meta-get , meta-get-tree , meta-ls and meta-set to say /usr/bin/gvfs-meta-get etc
The simple usage instruction can be gotten in the usual way, through the "-h" option.

Now to see what ~/.local/share/gvfs-metadata actually is used for, you can run:
gvfs-meta-get -r -f ~/.local/share/gvfs-metadata/user /
gvfs-meta-get -r -f ~/.local/share/gvfs-metadata/root /

And after analyzing the output on my Slackware 14.2 system I discovered that the ONLY extended attribute stored in this whole sorry mess was numerous "download-uri" put there by Mozilla browsers for everything they've ever done. As some perverted kind of permanent, indelible download history.

One can compile and run the above tool to make sure that on his/her own system, deleting the ~/.local/share/gvfs-metadata/* would not lose anything worth keeping. If so, the cleanup can be made a cron job or put into a shutdown script or whatever.

1 members found this post helpful.

fwiw, i have NO gvfs AT ALL on my system and it runs fine, incl. mounting my phone.

From wikipedia
and it is used a lot in other DE's, not just GNOME, too, like newer versions of XFCE (which is glib based too) and - as far as I know - KDE.

A pure Window manager will not use it, but I do not know if there are any Desktop Environments that CAN use FUSE but do not use gvfs for it.

all the big DE's file managers can use it to mount all sorts of stuff.
there's rarely a distro that does not install it by default.

on a redhat 6.9 machine i have encountered such issue:
increasing number of processes gvfsd-trash (/usr/libexec/gvfsd-trash --spawner :1.101 /org/gtk/gvfs/exec_spaw/xxx) one more per minute, immediately after the user has logged in and started his gnome desktop.

using strace it is possible to identify the resource(s) which are blocking gvfsd and causing increasing number of gvfsd-trash processes

gvfsdPID=$(pgrep gvfsd) # if several users on the machine use appropriate ps command to get PID of gvfsd owned by user encountering issue
strace -f -p $gvfsdPID
# wait 1 minute for gvfsd to fork its next gvfsd-trash
# see the traces, at the very end, it is trying to get a blocked resource. i my case i saw:

[pid 48477] access("/nobackup", R_OK <unfinished ...>

indeed, /nobackup was a blocked automount point (ls inside would never give the hand)

as temporary work-around, as root i unmounted lazy the blocked point:
umount -l /nobackup

then killed gvfsd process, which restarted and no more produced several gvfsd-trash processes

:-)