Dialog pops up saying. “This device could not be attached to the running machine. Would you like to make the device available after the next guest shutdown”.
Detailed message says “Operation not supported: live attach of device ‘filesystem’ is not supported…”
In the guest vm, I also tried to manually mount the “shared” directory and received an error.
user@host:~$ sudo mount -t 9p -o trans=virtio shared /mnt/shared
mount: /mnt/shared: bad option; for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program.
My host user is a member of the groups: kvm, libvirt, libvirt-qemu
The “/home/samplehostuser/shared” folder at the host is as follows…
$ ls -l -d /home/samplehostuser/shared
drwxrwxrwx 2 samplehostuser samplehostuser 4.0K Mar 8 11:43 /home/samplehostuser/shared/
I changed the group name of “/home/samplehostuser/shared” to kvm, libvirt and libvirt-qemu and still getting the permission error when starting up the Whonix-Workstation
If the emulated test fails, so would any application such as KVM doing the same.
(Not sure KVM should be called an application but in this context it doesn’t make a difference.)
/home/user owned by user user doesn’t easily mix with a sub folder accessible by another user. Since the parent folder /home/user is only accessible by user user the sub folder /home/user/afolder cannot easily be accessible by user user2.
On the host os, if I create the shared directory in /mnt/shared and set permission to 777, then the guest vm would start ok and guest vm app can access the shared directory
Scenario#2: This works
On the host os, if I create the shared directory in /mnt/shared and set permission to 770 and group=libvirt-qemu or group=kvm. The guest vm would start ok and guest vm app can access the shared directory. Setting the directory’s group to another other value would cause the guest vm startup to fail.
Scenario#3: This works
If the shared directory is within the host os’s user account. i.e. /home/samplehostuser/shared.
It is important to verify the following criteria:
/home/samplehostuser permission is 777 or
if /home/samplehostuser permission is 770, then libvirt-qemu must be a member of samplehostuser group
Note: (1) could have security consequences.
Request:
The documentation (Whonix ™ for KVM) is not clear on this and needs to be updated with these details
I still don;t know why the typical scenario documented already doesn’t work for you. I think all scenarios you listed are less ideal for different reasons which is why I can’t accept them.
The documentation as written didn’t work for me. The issue was it was not detailed enough with the folder permissions. I was simply asking to update the documentation with more details
In my case, my host user account permission is: /home/samplehostuser ... permission 770
and the shared folder permission is: /home/samplehostuser/shared ... permission 777
This would cause the Whonix-Workstation to fail on startup.
To fix this issue, I would need to set: /home/samplehostuser ... permission 777
or
add user ‘libvirt-qemu’ to group ‘samplehostuser’.
I hesitate because it could mess up permissions on a system level dir? Not sure of the consequences so I kept everything in home
The reason we add user to the libvirt group is because otherwise the user would have to input their user account password every time they open and interact with the VMM GUI
Not applicable… Because… What the user suggested is the other way arround.
is different from
add user user to gropu libvirt-qemu
I said:
No need for user libvirt-qemu to have full access to whole home folder of samplehostuser .
Clarification in other words:
I did not say:
No need for user user to have full access to libvirt-qemu.
Do not add user user to group libvirt-qemu.
The risk is minuscule. Linux folder permissions aren’t black magic.
It’s possible to view all file system settings one way or another.
stat /mnt
And after making modifications, checking again, seeing that nothing actually changed.
Since /mnt is and stays owned by user root, there should be no way for KVM to mess up that folder. It seems to respect folder permissions, otherwise there wouldn’t be this issue to begin with.
Also this could be turned around. Risking to mess up /mnt (which probably one most users’s systems doesn’t contain anything nowadays) vs risking to mess up /home, which would effectively brick the system for most users (not knowing how to use recovery mode). If permissions in /home or /home/user are messed up, that could even break login and X.
I’ve set permission of /home/samplehostuser/shared to 660. This creates a problem as I could not get into the directory as ‘samplehostuser’. So I set the permission to 760 (drwxrw----) and the Whonix-Workstation fails on startup.
$ sudo virsh start Whonix-Workstation
error: Failed to start domain Whonix-Workstation
error: internal error: process exited while connecting to monitor: 2021-03-15T15:23:12.203344Z qemu-system-x86_64: -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=shared,bus=pci.0,addr=0x8: share path /home/samplehostuser/shared does not exist