The VM manager will not share a host folder into a guest — it says it cannot find the daemon that does it

The component is a helper daemon that runs on the host, one instance per share, and serves the directory to the guest over a virtual device. The graphical manager does not launch it directly — it asks the virtualisation daemon to, and that daemon looks for the binary at a path recorded in its configuration. So there are two ways to be in your situation: the binary is genuinely missing, or it is installed somewhere other than where the daemon expects.

Given you have installed a package already, the second is more likely, and it happens for a specific reason: the daemon was rewritten and moved between packages. The original implementation shipped with the emulator package. The current one is a standalone project and distributions package it separately, frequently under a different name, and occasionally install it to a different directory. So a system upgraded across that transition can end up with a configuration pointing at the old location and a binary at the new one.

Work through it like this:

1. Find whether the binary exists at all. Search the usual system directories for it by name. Note that it commonly lives in a system daemon directory rather than on your path, so simply typing the name and getting "command not found" proves nothing.
2. If it is absent, install the standalone package. Search your package manager for the name rather than guessing — it varies between distributions, and on some it is bundled into the general virtualisation tooling package rather than having its own.
3. If it exists but is not being found, tell the virtualisation daemon where it is. There is a configuration setting for exactly this path. Set it to the actual location and restart the virtualisation daemon, which is the step people miss — editing the file alone changes nothing until the daemon reloads.
4. Check the security policy, which is the other common cause. Mandatory access control on the host may deny the daemon permission to execute the binary or to read the directory you are sharing. The symptom is confusingly similar to the binary being missing. Look at the host's audit log immediately after a failed start; a denial there is unmistakable and points at the exact rule.

Two things on the guest side, because getting the host right only gets you half way:

• The guest kernel needs the driver for this filesystem type, which is present in current kernels but may need loading. Without it the machine starts and the share is simply absent, with no error on the host.
• The share has to be mounted in the guest, with the tag you configured. Adding it in the manager exposes the device; it does not mount it. Then add it to the guest's filesystem table so it survives a reboot.

One design note worth having before you invest in this: this mechanism needs shared memory backing for the guest, which the manager usually configures for you but which conflicts with some memory settings — notably ballooning and certain huge-page configurations. If the machine refuses to start with a memory-related error after you add the share, that is what happened, and the fix is in the memory configuration rather than the share.

If you only need occasional file access and not performance, a plain network share is far less machinery and always works. This is worth the setup when you are sharing a large directory that the guest reads heavily.

The security policy point is the one I would check second, right after confirming the binary exists, because the error surfaces so misleadingly.

On a distribution with mandatory access control enabled, sharing a directory from an unusual location — a home directory, an external mount, anything outside the paths the policy expects for virtual machine storage — gets denied. The manager reports a generic start failure and the useful message is only in the host's audit log.

Worth knowing the shape of the fix: either relabel the directory so the policy permits it, or share from a location the policy already allows. Turning the policy off entirely is the advice you will find most often and it is the worst of the options.

On performance, since it is usually why people choose this over a network share: it is substantially faster for many small files, which is the case a network share handles worst. Compiling inside a guest against a shared source tree is the classic example and the difference is large.

It is less of a win for a few big sequential files, where a network share is already close to disk speed.

So if you are sharing a media directory, do not do this work. If you are sharing a source tree or anything with a lot of metadata operations, it is worth the setup.

Small thing that saved me once the share finally worked: check the ownership mapping.

User and group ids inside the guest are not automatically the same as on the host, so files can appear owned by nobody, or be unwritable, even though the share is mounted correctly. There are options controlling how identities are mapped.

Easy to mistake for the share not working properly when actually it is working perfectly and you cannot write to it.