This is a perpetual problem for people who develop FUSE file systems. This link may help (it s quite literally too much to consolidate in a single answer). The work-around involves a just-in-time replacement of fusermount, and (depending), some additional options to valgrind to prevent it from tracing children.

In fact, if you run my FS under valgrind, you get this output (yes, enough people had that problem that I actually detected valgrind on start up and displayed the link):

root@tower:~ # valgrind xsfs /xs
==9479== Memcheck, a memory error detector.
==9479== Copyright (C) 2002-2008, and GNU GPL d, by Julian Seward et al.
==9479== Using LibVEX rev 1884, a library for dynamic binary translation.
==9479== Copyright (C) 2004-2008, and GNU GPL d, by OpenWorks LLP.
==9479== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==9479== Copyright (C) 2000-2008, and GNU GPL d, by Julian Seward et al.
==9479== For more details, rerun with: -v
==9479==
******** Valgrind has been detected by xsfs
******** If you have difficulties getting xsfs to work under Valgrind,
******** see the following thread:
******** http://www.nabble.com/valgrind-and-fuse-file-systems-td13112112.html
******** Sleeping for 5 seconds so this doesn t fly by ....

The easiest thing to do is all of your debugging in a disposable VM running as root, where you can just ditch the setuid bit, and be done with it. Make sure you test your code to not have any leaks or violations, its easy enough to test any linked library code not using fuse. Hand your build off valgrind-clean and note that you ve done so in the documentation.

Then, grab some bits out of valgrind/valgrind.h to detect it, and show a short message for those that go ahead and run it anyway. Hacks to work around it require root cooperation, and quite frankly, are much easier done in a sandbox just as well.

It s also easy enough to refuse to run under valgrind with the setuid bit on, showing a helpful message for people to turn it off if they really want to do it.

I suppose most simple answer would be to remove setuid/setgid bit while debugging. Of course if the program really needs root privileges you will have to probably run valgrind as root or since valgrind itself seems to be setuid just chown it to root:root. If you execute valgrind after that it will have root privileges (and so will it s children - debugged processes).

You should then be able to run valgrind on that application.

Just be careful, because you will be introducing a BIG security hole in your system. Safer solution would be to create special group only for users that should be able to run (setuid) valgrind and go from there...

I m assuming you tried running it with --trace-children=no? If you have root access, there appears to be a workaround here.

Run the valgrind command as root (or whoever the set-uid user is), then the program won t have to make use of setting the uid.

This happens even when things were run as root user :) Best way is to change the perms to remove "s", and run