This would replace the chown command yes.
Yes that must be why since the “-m” parameter takes a user group name argument. Is there something like the libvirt-qemu group for Fedora instead?
While its a good thing you have something working this command should make it seamless if we succeed in working it out on your distro.
I see three potentially relevant groups:
Of these groups, there is only one corresponding “user”: qemu.
How would you suggest revising the command?
It would be
u:libvirt
But to be completely sure you would check the group that the files transferred from the VM belong to (before chowning or changing permissions on them)
“u:libvirt” produces the same error as “u:libvirt-qemu”:
setfacl: Option -m: Invalid argument near character 3
I suspect the issues is the lack of a defined libvirt user in Fedora.
setfacl also accepts groups … ie. g:libvirt, but perhaps that is something different altogether. Are you certain the focus of the command should be the “user” and not the “group”?
To check ownership or permission requests coming from the guest may be tricky, as the rights need to be modified just to add a file to the “shared” folder in Workstation. I understand that SELinux “permissive” mode logs all file requests. The log may offer a positive ID of the requesting user and/or group that holds rank in the guest system.
I will study-up on how to find and read the SELinux logs, and also, whether or not there is need to add a libvirt user to the Fedora host.
I figured it out if anyone out there still cares. The only command you need to make shared files accessible in the host and guest is:
sudo chmod 777 -R /home/yourusername/shared
The longer command I had originally was wrong. Thanks for reporting this.
I’m using a Fedora 28 host with the latest version of Whonix 13. As other users described above in this thread, my folder shared fails to mount at startup. When using the suggested workaround: sudo mount -t 9p -o trans=virtio,version=9p2000.L shared /mnt/shared, it mounts but I get permission denied when accessing files copied from the host. I did run chmod 777 -R from the host.
hi. This was a bug with Whonix 13. Please try the test version of Whonix 14 which should solve the mounting problem. As for Fedora hosts you also have to cope with SELinux permissions to be able to use your files from the guest. Have you handled this?
I’ve been looking for it. Where is the download link for V14?
Hi frederic
I installed V14. Same problem. This time, the drive mounts just fine at startup (no need to mount manually). However, the result is the same. I can access the mount, but I get “permission denied” when trying to ls from a directory created from the host. I did chmod 777 on the folder.
Verify if this works for you and I’ll add it to the wiki:
If you don’t have SELinux enabled everything should work now. If you do (which I recommend), you will need to add a policy for files under your /share folder on your host. SELinux won’t allow you to share this folder until it’s labeled svirt_image_t. Here is how to add this policy on your host using semanage:
root@host# semanage fcontext -a -t svirt_image_t “/share(/.*)?”
root@host# restorecon -vR /share
Hi there, have a problem with sharing folder.
Did everything by the manual Whonix ™ for KVM but after Workstation rebooted, sharing folder doesn’t appear.
Any suggestions?
System is newly installed Whonix XFCE.
Apparmor or SELinux? Host distro and version?
Unfortunately I couldn’t find it reported anywhere. Though Debian testing is expected to not be as stable as stable. The good news is Debian devs [0] are active on the pureOS bug tracker and will help you debug and fix this. Open a ticket and tag “guido” the libvirt maintainer to help.
Please link to your report here so others can track your progress.
Little update: Mounted folder finally was found in /mnt/ directory but read or edit function on host-system side doesn’t work if copy file/folder to “shared” folder from Workstation.
I get the message “Failed to open directory (Directory Name). Error opening directory (directory patch): Permission denied” until I type in terminal sudo chmod -R 777 (shared folder path).
So it’s necessary type “sudo chmod -R 777 (shared folder path)” to get permissions on host after each add files or folders process in Workstation system.
Unfortunately this is how it works though hypothetically you can script this.