Comment # 8 on bug 978424 from Mike Latimer

Some testing on the systemd service Mario suggested in comment #4, shows that
with such a service, vmware-vmblock-fuse will start with the following command
line:

/usr/bin/vmware-vmblock-fuse -d -f -o
subtype=vmware-vmblock.default_permissions.allow_other /run/vmblock-fuse

However, users still encounter the "could not open /proc/fs/vmblock/dev"
message as they do not have permissions to read /var/run/vmblock-fuse/dev. The
root user can run vmware-user-suid-wrapper without any errors, but I have not
seen any any real changes in the environment.

When using drag-and-drop, a file being copied to the VM will temporarily be
written to a /tmp/VMwareDnD/<hash> directory. If vmware-vmblock-fuse is
running, the /var/run/vmblock-fuse/blockdir/ directory gets a symlink to this
hash directory, but again, this does not seem to really change anything.

For example, after dragging and dropping a file called "test.txt"

# ls -l /tmp/VMwareDnD/21d878a6/
-rw-r--r-- 1 guest users 4004 Mar  9 14:37 test.txt

# ls -l /var/run/vmblock-fuse/blockdir/
total 0
lrwxrwxrwx 1 root root 23 Jun  9 14:44 21d878a6 -> /tmp/VMwareDnD/21d878a6

# ls -l /var/run/vmblock-fuse/blockdir/21d878a6/
-rw-r--r-- 1 guest users 4004 Mar  9 14:37 test.txt

Would a vmblock-fuse service be one way to automatically mount any shared
folders? This is something that you get with VMware Tools, but there is no
automounting of shared folders with open-vm-tools. (It's easy to run
`vmhgfs-fuse .host: <some_writeable_mount_point>`, but auto-mounting the shared
folders might make it easier for people to find them.)