VirtIO-FS Service crashes with error 87 in Windows 10 guest

[kachapman]

Describe the bug Trying to start the VirtIO-FS service fails with error 87.

To Reproduce Steps to reproduce the behaviour: Followed the steps online (https://www.debugpoint.com/kvm-share-folder-windows-guest/) to add a hardware file system using virtiofs as the driver in virt-manager, the source path is my local documents folder in my home directory and the target path is linux-docs. Installed WinFSP and virtio-win-guest-tools in the windows 10 guest without issue, making sure that the core components needed were selected. Drivers all appear to be signed correctly with the right information. Restarts done when asked. Go to start the service and it fails.

One thing I thought was odd was that if I deleted the added file system hardware in virt-manager, the service would start no problem. I tried changing the local director and that didnt help. If I start the service, then add the hardware filesystem, it wont recognize or mount anything either.

Expected behavior The service should have started, and my documents folder mounted as volume Z: in windows.

Screenshots

Host:

• Disto: Pop!_OS 22.04 LTS
• Kernel version: 6.4.6-76060406-generic
• QEMU version
• QEMU command line
• libvirt version
• libvirt XML file

VM:

• Windows version: 10

[YanVugenfirer]

@kachapman Did you change any parameters or registry settings of the virtio-fs service after installations?

[kachapman]

No changes like that. Just trying different things on the virt-manager > add hardware side. Is there a log file that I could post that would help?

[morales-roman]

PopOS 22.04 Virt Manager version: 4.0.0 QEMU emulator version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.13) libvirtd (libvirt) 8.0.0 VM: W10 22H2 19045.3448

I have the exact same error and behavior @kachapman described.

Let me know if I can generate logs for you.

[ranged7176]

I had the exact same problem as well. Host:

• Ubuntu Mate 22.04.3 LTS
• virt-manager 4.0.0-1
• qemu 6.2.0 (1:6.2+dfsg-2ubuntu6.13)
• libvirt 8.0.0 (8.0.0-1ubuntu7.6)

Guest:

• Windows 10 22H2 19045.3324

[Polar7454]

Have the same issue, Error 87. Uninstalled winfsp and virtio guest tools through BCuninstaller and reinstalled, issue still persists.

Used Powershell with admin privileges to launch: sc create VirtioFsSvc binpath="C:\Program Files\Virtio-Win\VioFS\virtiofs.exe" start=auto depend="WinFsp.Launcher/VirtioFsDrv" DisplayName="Virtio FS Service"

Got error: Set Content : A positional parameter can not be found that accepts argument 'binpath=C:\Program Files\Virtio-Win\VioFS\virtiofs.exe' line=1 char=1

CategoryInfo : Invalid Argument (:) [Set content], Parameter Binding Exception FullyQualifiedErrorId : PositionalParameterNotFound, Microsoft.Powershell.Commands.SetContentCommand

Host:

Linux Mint 21.2     on an ext4 file system
Kernel version: 6.2.0-32-generic
virt-manager 4.0.0
qemu 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.13)
libvirt 8.0.0

Guest:

Windows 10 22H2 19045.2965  on an ntfs file system
WinFsp 2.0.23075
Virtio-win-guest-tools 0.1.229.0   (30.6MB)

[kachapman]

I don't know if this information helps, but I have a possibly related glitch where I have to reinstall the spice guest tools every time I spin up the Windows 10 VM, otherwise I dont have the copy/paste and drag/drop from host functionality. But the webdav spice functionality is still there (the mounted drive from the host machine).

[haraldthi]

Same here.

Host: Linux Mint 21.2 on Btrfs. Kernel version: 5.15.0-76-generic virt-manager 4.0.0 libvirt 8.0.0

Guest: Windows 11, installed yesterday and recently updated. WinFsp 2.0.23075 and so on.

I tried installing the latest Virtio-win-guest-tools (as of today) to see if someone had come up with a way to fix this, but no help.

[rhardy613]

I really wish the shared folder setup here was more automatic and user friendly. I need a shared folder that starts reliably if the guest tools are installed and it is configured once for the VM. Something is fundamentally broken now. Not sure what.

I too am suddenly faced with this mess with a Win 10 22H2 VM hosted on Ubuntu 22.04. Previous to today, I was on winfsp-1.11.22176 and it stopped working. In the past it has had issues with various events preventing the service from starting. Last month I had to start it manually and it worked for the session last month. Now it won't work at all. I tried deleting the service, uninstalling, restarting, upgrading to WinFSP 2.0.23075 and then recreating the service. I am still stuck with the same failure mode and error 87 on service start.

I tried starting the service manually with debugging turned on using:

C:\Program Files\Virtio-Win\VioFS>virtiofs.exe -d -1 -D C:\log2.txt The service VirtIO-FS has failed to start (Status=c000000d).

This put the following text in the C:\log2.txt file: VirtFsFuseRequest: >>req: 26 unique: 2 len: 56 VirtFsFuseRequest: <<len: 16 error: -22 unique: 2

That doesn't really help me figure out what is broken here... Does the error log mean something to someone else here?

[viktor-prutyanov]

*** VirtFsFuseRequest: >>req: 26 unique: 2 len: 56
*** VirtFsFuseRequest: <<len: 16 error: -22 unique: 2

It means that FUSE_INIT is failed with EINVAL. So, please share virtiofsd (host daemon) logs.

[kachapman]

I really wish the shared folder setup here was more automatic and user friendly. I need a shared folder that starts reliably if the guest tools are installed and it is configured once for the VM. Something is fundamentally broken now. Not sure what.

I too am suddenly faced with this mess with a Win 10 22H2 VM hosted on Ubuntu 22.04. Previous to today, I was on winfsp-1.11.22176 and it stopped working. In the past it has had issues with various events preventing the service from starting. Last month I had to start it manually and it worked for the session last month. Now it won't work at all. I tried deleting the service, uninstalling, restarting, upgrading to WinFSP 2.0.23075 and then recreating the service. I am still stuck with the same failure mode and error 87 on service start.

I tried starting the service manually with debugging turned on using:

C:\Program Files\Virtio-Win\VioFS>virtiofs.exe -d -1 -D C:\log2.txt The service VirtIO-FS has failed to start (Status=c000000d).

This put the following text in the C:\log2.txt file: VirtFsFuseRequest: >>req: 26 unique: 2 len: 56 VirtFsFuseRequest: <<len: 16 error: -22 unique: 2

That doesn't really help me figure out what is broken here... Does the error log mean something to someone else here?

The mistake I made was moving over to this VM setup, instead of virtual box. I never had folder sharing or drag/drop issues on that platform. But I did suddenly lose 3d acceleration because of virtual box updates, which I was putting up with because my work software isnt that demanding. But then I saw some recommendations from several you tubers and forum posters to switch to virt-manager because its 'faster and simpler'. Faster, maybe. But wow is it unnecessarily complicated if you want to run a windows VM with any kind of production related functionality.

Same here.

Host: Linux Mint 21.2 on Btrfs. Kernel version: 5.15.0-76-generic virt-manager 4.0.0 libvirt 8.0.0

Guest: Windows 11, installed yesterday and recently updated. WinFsp 2.0.23075 and so on.

I tried installing the latest Virtio-win-guest-tools (as of today) to see if someone had come up with a way to fix this, but no help.

Well that sucks. I just downloaded a win 11 ISO to see if that would solve the issue.

[kachapman]

*** VirtFsFuseRequest: >>req: 26 unique: 2 len: 56
*** VirtFsFuseRequest: <<len: 16 error: -22 unique: 2

It means that FUSE_INIT is failed with EINVAL. So, please share virtiofsd (host daemon) logs.

Is this something I could provide as well? How would I get access to those?

[viktor-prutyanov]

I suggest to share the following things:

1. virtio-win version
2. virtiofsd version
3. virtiofsd logs

[viktor-prutyanov]

@kachapman

Is this something I could provide as well?

Of course.

How would I get access to those?

It depends on how do you run it.

[rhardy613]

I'm glad to provide whatever will help to get to the bottom of this but the how and where was missing from this. I'm going to grab the log from the host and try to fill in the blanks. virtio-win-0.1.229 virt-manager 1:4.1.0-2~jammy1

strings /usr/lib/qemu/virtiofsd | grep version [manually trimmed] virtiofsd version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.13)

Host-fs0-virtiofsd.log That log file has a lot of lines but the cause details are sparse to me anyways.

[viktor-prutyanov]

Please try the modern virtiofsd (Rust version) instead of deprecated one

[rhardy613]

How? There appears to be non packaged install process for this here which I can't use on a production system: https://gitlab.com/virtio-fs/virtiofsd Surely if this is critical to virtio-fs actually working someone has actually packaged this? virtiofsd appears to be part of the qemu-system-common package which is 1:6.2+dfsg-2ubuntu6.13 on Ubuntu 22.04. There are newer 7.2 series packages of qemu in some PPAs but it isn't clear at all if that contains what you suggest.

[kachapman]

Please try the modern virtiofsd (Rust version) instead of deprecated one

Are you talking about the files here? https://gitlab.com/virtio-fs/virtiofsd/-/releases

This is just a single file. Do I replace another file from the virtio-win-guest-tools install package with this one?

[rhardy613]

On Ubuntu 22.04 this appears to be a regression in qemu 1:6.2+dfsg-2ubuntu6.13 which is fixed in qemu 1:6.2+dfsg-2ubuntu6.14. https://answers.launchpad.net/ubuntu/+source/qemu/+question/707811 There is a package in proposed so that should be released shortly. For now the bug mentions a PPA that can be used to try the fixed packages: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2033957 This is the PPA with the fix in it: https://launchpad.net/~sergiodj/+archive/ubuntu/qemu-bug2033957 Obviously the rust version would be best but until someone gets around to packaging that this at least gets things operational again. I work in actual engineering. Randomly replacing exe leads to chaos with non-reproducible systems. Yes that will get you the latest code but it is a support nightmare. I would stick to supported reproducible fixes.

[erenoglu]

I can confirm the same issue on Ubuntu 22.04 and Win10 guest. Logs from Guest:

VirtFsFuseRequest: >>req: 26 unique: 2 len: 56 VirtFsFuseRequest: <<len: 16 error: -22 unique: 2

Logs from Host:

:/var/log/libvirt/qemu# cat win10-fs0-virtiofsd.log virtio_session_mount: Waiting for vhost-user socket connection... virtio_session_mount: Received vhost-user socket connection virtio_loop: Entry fv_queue_set_started: qidx=0 started=1 fv_queue_set_started: qidx=1 started=1 fv_queue_thread: Start for queue 0 kick_fd 9 fv_queue_thread: Start for queue 1 kick_fd 12

I dont see anything significant. I tried to restart the guest service couple of time, nothing appears in host logs other than those lines.

XML (I added queue=1024 myself):

[viktor-prutyanov]

Guys, I don't know why your favorite Linux distros contains deprecated virtiofsd (C version). It was deleted from QEMU in January 2023. The supported one is the Rust version from https://gitlab.com/virtio-fs/virtiofsd/ . Both RHEL and Fedora already have a package with the supposed version.

[erenoglu]

I understand @viktor-prutyanov , unfortunately Ubuntu 22.04 is required due to reasons which I can't control. otherwise I'd be using Arch as I did many many years :(

[viktor-prutyanov]

@erenoglu It is easy to build virtiofsd: cargo build

[rhardy613]

Ubuntu 22.04 is a long term support release. Unfortunately it appears to be lagging greatly. Debian has newer packages but they aren't getting pulled in for some reason. Ubuntu 24.04 will likely have it. I'm trying to see if the Debian package of 8.1 could be back ported but it is likely a bigger job. Yes it is easy to do that but that depends if you are allow to put un-packaged software on systems. Here doing that is against security policy.

[kachapman]

On Ubuntu 22.04 this appears to be a regression in qemu 1:6.2+dfsg-2ubuntu6.13 which is fixed in qemu 1:6.2+dfsg-2ubuntu6.14. https://answers.launchpad.net/ubuntu/+source/qemu/+question/707811 There is a package in proposed so that should be released shortly. For now the bug mentions a PPA that can be used to try the fixed packages: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2033957 This is the PPA with the fix in it: https://launchpad.net/~sergiodj/+archive/ubuntu/qemu-bug2033957 Obviously the rust version would be best but until someone gets around to packaging that this at least gets things operational again. I work in actual engineering. Randomly replacing exe leads to chaos with non-reproducible systems. Yes that will get you the latest code but it is a support nightmare. I would stick to supported reproducible fixes.

Ok, so these temporary fixes could be applied now to resolve the issue, but a package is incoming?

@erenoglu It is easy to build virtiofsd: cargo build

Would building it manually resolve the issue?

[rhardy613]

There is already a package in proposed that fixes the issue. You can try that using the PPA. People are reporting it addresses the issue. I am about to try it.

[kachapman]

There is already a package in proposed that fixes the issue. You can try that using the PPA. People are reporting it addresses the issue. I am about to try it.

Would you be able to walk me through the update process with that package? I have the .tar, but Im not sure where to put these files, or if there is a install script in here somewhere.

[erenoglu]

Hi @kachapman , it's easy as decribed in the site linked by @rhardy613 : https://launchpad.net/~sergiodj/+archive/ubuntu/qemu-bug2033957

Just do these two commands in a terminal window:

sudo add-apt-repository ppa:sergiodj/qemu-bug2033957 sudo apt update

Then a normal system upgrade shall install the corrected packages,

sudo apt upgrade

[rhardy613]

Yes, I just tried the bug fix .14 one from the PPA and it resolved this for me. I would remove that PPA once the packages are in production.

[kachapman]

Yes, I just tried the bug fix .14 one from the PPA and it resolved this for me. I would remove that PPA once the packages are in production.

This resolved the issue for me as well. Host directory now mounts by default. Still have the other issue where I have to reinstall spice-guest-tools-latest each bootup, in order to get copy/paste from the host. But thats outside of the scope of this issue (I think).

[bussiereThomas]

Hi, I got the same issue, following the thread. Unfortunately ppa didn't fix the problem on Ubuntu 22.04 (upgraded from 20.04 if it's change anything at all) qemu-system-x86_64 --version QEMU emulator version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.14~ppa1)

[YanVugenfirer]

Hi, I got the same issue, following the thread. Unfortunately ppa didn't fix the problem on Ubuntu 22.04 (upgraded from 20.04 if it's change anything at all) qemu-system-x86_64 --version QEMU emulator version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.14~ppa1)

@bussiereThomas Can you please check what virtiofsd is used in your setup?

[YanVugenfirer]

Hi, I got the same issue, following the thread. Unfortunately ppa didn't fix the problem on Ubuntu 22.04 (upgraded from 20.04 if it's change anything at all) qemu-system-x86_64 --version QEMU emulator version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.14~ppa1)

In any case, Rust virtiofsd is no longer part of QEMU.

[YanVugenfirer]

Rust virtiofsd solved the issue. Closing.