Bug 988641

What is the error?  Look at dmesg and copy any errors there too.

Richard, if you remember we had this discussion in the original bug too. open-vm-tools package contains only user space components. Shared folder requires hgfs kernel driver to work. So, this is expected behavior.

Currently, one needs to get the hgfs driver either by building it from open-vm-tools source code or install new version of VMware Tools (yet to be released) that would let you install the missing drivers without having to uninstall open-vm-tools.

Long term plan is to get rid of the kernel driver piece.

I would like to close this bug because we are aware of this and working on it indirectly.

OK, this makes sense.

To the reporter: This cannot be fixed because Fedora
doesn't allow non-upstream kernel modules to be added.
Therefore you either have to build your own kernel (or module)
or wait for this to be fixed upstream (see previous comment).

Couple of questions:

1.) Do you have a quote that justifies the statement "Fedora
doesn't allow non-upstream kernel modules to be added"? It is, at best, non obvious. The kernels license certainly allows to ship additional modules, and the open-vm-tools are distributed under the terms of GPL, version 2, so they are quite compatible with the kernel license.

2.) If Fedora can't ship the module itself, it should at least be possible to ship it as part of RPMFusion, or something similar. Could you drop some words on what needs to be done technically to achieve that.

Thanks,

Jochen

1) https://fedoraproject.org/wiki/Packaging:Guidelines#No_External_Kernel_Modules

2) It would certainly be possible to ship it as an akmod in
RPMFusion.  Apparently this is how to do that:
http://rpmfusion.org/Packaging/KernelModules/Akmods

I'd actually much prefer that the module went upstream, but I've
no idea what's involved with that, or indeed why it's not upstream
now.  Maybe there's a licensing issue?  I guess VMware can provide
the answer to that.

A more important information: In general, the Kernel module isn't needed, because the open-vm-tools contain a program called vmhgfs-fuse, and I can mount a shared VMWare folder named "foo" like this:

    # Show a list of all folders:
    $ vmware-hgfsclient
    foo

    # Create a directory /home/user/windows, and mount the shared folder
    mkdir /home/user/windows
    vmhgfs .host:foo /home/user/windows

Note, in particular, that no root privileges in the Linux guest are required.

(In reply to Richard W.M. Jones from comment #5)
> I'd actually much prefer that the module went upstream, but I've
> no idea what's involved with that, or indeed why it's not upstream
> now.  Maybe there's a licensing issue?  I guess VMware can provide
> the answer to that.

Thanks Richard. There is no licensing issue. It is just that the kernel driver is not ready for upstream and it will require lot of convincing Linux kernel community to accept yet another filesystem driver in presence of NFS and SMB alternatives already being there.

(In reply to Jochen Wiedmann from comment #6)
> A more important information: In general, the Kernel module isn't needed,
> because the open-vm-tools contain a program called vmhgfs-fuse, and I can
> mount a shared VMWare folder named "foo" like this:
> 
>     # Show a list of all folders:
>     $ vmware-hgfsclient
>     foo
> 
>     # Create a directory /home/user/windows, and mount the shared folder
>     mkdir /home/user/windows
>     vmhgfs .host:foo /home/user/windows
> 
> Note, in particular, that no root privileges in the Linux guest are required.

Yes, that's right. open-vm-tools v10.0.0 ships Fuse based solution now. We no longer require vmhgfs kernel driver for Shared Folders. So, let's not worry about the driver, just use open-vm-tools v10.0.0 or later :)