In some sense this is correct :-)

Try doing the following command in guestfish (requires the "run"
command to have been done first):

><fs> supported

At the end of the list you should see "zerofree no" indicating that
the zerofree command isn't available in the daemon.

Also:
http://libguestfs.org/guestfs.3.html#availability

However it may be that we need to either:
(1) Add zerofree as a new package to RHEL 6 (probably not
advisable, it's a rather experimental package which can destroy
filesystems if it is not used correctly)

(2) Improve the error message.

Anyway, this is a 6.2 thing I think, so I have reset the flags
to 6.2 ...

Well. If zerofree is too dangerous to RHEL 6, why is it still in libguestfs since it could be impossibly available?

Some groups (like ntfs3g) are optional by providing a separate support package. But we'll never get zerofree. Shouldn't it be removed from libguestfs like in 6.0?

The problem is that if we remove the underlying API (ie.
guestfs_zerofree) then some programs wouldn't compile.

If programmers are following the documentation, then
they should be calling guestfs_available first before
using guestfs_zerofree, and they should also check the
return value from guestfs_zerofree for errors.

We could remove it leave it in the API but remove it from
guestfish, but that just makes guestfish irregular -- we
document that guestfish has an equivalent for every
libguestfs API call.

Also it is conceivable that a RHEL 6 user could prepare a
package containing zerofree + the relevant supermin
appliance changes which would transparently add zerofree
support back into libguestfs.  This is roughly what
libguestfs-winsupport does for ntfs-3g.

I don't think there is a good answer to this, although
improving the error message would be a good idea.

6.3 material, unless a customer complains about this.

zerofree is dangerous.  To add it to RHEL we'd need to
have the code fully and properly checked by Ric Wheeler
and friends.

Reproducer:

$ guestfish -N fs zerofree /dev/sda1
libguestfs: error: zerofree: /dev/vda1: zerofree: No such file or directory

Note this creates/overwrites a file in the current directory
called 'test1.img', so:

$ rm test1.img

Patch posted:

https://www.redhat.com/archives/libguestfs/2012-February/msg00000.html

Updated patch posted:

https://www.redhat.com/archives/libguestfs/2012-February/msg00002.html

Committed upstream:

https://github.com/libguestfs/libguestfs/commit/330fbea5b2d6bd7db84f7ea7afe87cf1bcd438e0

The patch is incomplete and causes the daemon to
segfault in some circumstances.  Patch posted to
fix that:

https://www.redhat.com/archives/libguestfs/2012-February/msg00057.html

Fix included in libguestfs 1.17.7:
https://github.com/libguestfs/libguestfs/commit/ba443ae0486ae30ea597c4e126de63371f8fa7a8
and this will be backported to 1.16 branch and RHEL 6.3.

The fix is included in upstream stable branch version
1.16.5, and in RHEL 6.3 build (same version).

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
No Documentation needed

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2012-0774.html