Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Viktini opened this issue Nov 4, 2024 · 3 comments
Assignees

Comments

@Viktini
Copy link

Viktini commented Nov 4, 2024

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
Copy link
Collaborator

ybendito commented Nov 4, 2024

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

@Viktini
Copy link
Author

Viktini commented Nov 4, 2024

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
Copy link
Author

Viktini commented Nov 6, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants