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:
- 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.
- 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.
- 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.
- 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.