virtiofs: "A device attached to the system is not functioning." after attempting to save an edit on MusicBee, even with queue=1024

[Viktini]

Describe the bug
Whenever an attempt to save an edit to a file's metadata on MusicBee is done and then another file is played, an error from MusicBee will show up, saying that "A device attached to the system is not functioning."

This occurs even with queue=1024 set as well as -F NTFS in the service properties.

The edits to the tags are not saved whatsoever and library corruption can occur if the library is stored on the mounted share, as MusicBee sometimes has trouble saving the library - presumably for the same reason.

To Reproduce

1. Load MusicBee
2. Edit a file's metadata using the built-in tag editor
3. Switch to another file in MusicBee.
4. Observe that it failed to save the file, citing a device attached to the system is not functioning.

Expected behavior
MusicBee saves the file without complaining about a device not functioning.

Host:

• Ultramarine 40 (based on Fedora 40)
• 6.11.5-200.fc40.x86_64
• QEMU version 8.2.7
• libvirt 10.1.0
• libvirt XML file

VM:

• Windows 11
• Virtiofs
• Version 100.95.104.26200 (via Device Manager / VirtIO FS Device properties)

Additional context
Log from MusicBee - note that the attempts to edit were done to the Carly Rae Jepsen tracks, not the Avicii one.

I can try to find more logs when directed - just let me know. This might not be limited to MusicBee but it's the app I tend to use most on a Windows VM.

[ybendito]

@Viktini please first of all look at system log (journalctl -b) something related to virtiofsd process, for example process crash.

[Viktini]

journalctl -b | grep virtiofs came up with a lot of AVC in the logs. I presume that maybe SELinux is interfering? Ultramarine, much like its upstream, uses SELinux.

https://gist.github.com/Viktini/e00dd87b6455aaa4c6fa8478f888cd77

EDIT: Added myself to the libvirt group, no change, also tried permissive mode and even disabling SELinux, no change there. I do plan to test this issue on CachyOS (based on Arch Linux) as well as I've been having unrelated issues with Ultramarine, but I can still quickly test on that distro if needed.

[Viktini]

Just popping in to say that virtiofs works fine on CachyOS. 6.11.6-2-cachyos, QEMU 9.1.1, libvirt 10.9.0, VirtIO FS Driver version 100.95.104.26200 on the Windows 11 VM. SELinux is not installed.

I'm going to guess that it was an issue with either an older version or an issue with SELinux.

[xiagao]

Sorry, I didn't reproduce this issue even with selinux=Enforcing.

The test env:
virtiofsd-1.11.1-1.el9.x86_64
qemu-kvm-9.1.0-1.el9.x86_64
edk2-ovmf-20240524-7.el9.noarch
kernel-5.14.0-516.el9.x86_64
virtio-win-prewhql-0.1-262

guest version: Win11 version 24H2, os build 26100

Steps:

1. enable selinux on host
   getenforce
   Enforcing
2. start qemu-kvm to start a Windows 11 os with a shared virtiofs device, driver version is 262.
3. Install Musicbee app to the shared virtiofs volume Z:\
4. And Create a music store folder in Z:\ and put some .mp3 files to Z:\music\
5. Right click one .mp3 file in musicbee, and edit it with 'Tags' tag, click 'Save' button
6. Check the modified .mp3 in Z:\music\

Actual result:
The .mp3 file info was updated, no shared volume crash.