So apart from manually mounting the share folder via command, is there a simple fix I should implement on my end?
Regarding Whonix 14, any rough time-frame for a release?
Cheers!
kdesudo kwrite /lib/systemd/system/mnt-shared-kvm.service
Replace the contents with:
https://raw.githubusercontent.com/Whonix/shared-folder-help/master/lib/systemd/system/mnt-shared-kvm.service
Save and restart.
Whonix 14 release will take a while since it depends Stretch stabilizing.
1 Like
Thanks. KVM now mounts shared folders in the boot up and the folders now appear in the guest.
I note that the instructions for configuring the shared folder have now been revised on the Whonix KVM web page. In that regard, the instruction below to configure ownership via the host would seem to make it impossible to have write access to the shared folder and its content. In fact, this is indeed the case, write permission is denied via the guest.
“sudo chown -R yourusername /home/yourusername/shared && sudo chmod 777 -R /home/yourusername/shared”
Can you recommend an ownership configuration that would permit two-way traffic in the shared folder?
1 Like
OKay, so my comment above refers to a test that I ran installing Whonix on KVM in Debian – after your suggestion about switching distros.
I did a fresh test today installing KVM and Whonix on a new Fedora 25 install and Workstation completely fails to boot, giving the following error:
Error starting domain: internal error: process exited while connecting to monitor: 2017-03-21T06:30:18.197966Z qemu-system-x86_64: -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=shared,bus=pci.0,addr=0x9: 9pfs Failed to initialize fs-driver with id:fsdev-fs0 and export path:/home/u1/shared
Traceback (most recent call last):
File “/usr/share/virt-manager/virtManager/asyncjob.py”, line 88, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File “/usr/share/virt-manager/virtManager/asyncjob.py”, line 124, in tmpcb
callback(*args, **kwargs)
File “/usr/share/virt-manager/virtManager/libvirtobject.py”, line 83, in newfn
ret = fn(self, *args, **kwargs)
File “/usr/share/virt-manager/virtManager/domain.py”, line 1479, in startup
self._backend.create()
File “/usr/lib64/python2.7/site-packages/libvirt.py”, line 1035, in create
if ret == -1: raise libvirtError (‘virDomainCreate() failed’, dom=self)
libvirtError: internal error: process exited while connecting to monitor: 2017-03-21T06:30:18.197966Z qemu-system-x86_64: -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=shared,bus=pci.0,addr=0x9: 9pfs Failed to initialize fs-driver with id:fsdev-fs0 and export path:/home/u1/shared
Thanks for the heads up. I have to adjust instructions.
With Fedora you have SELinux permissions to sort out which are another source of endless headaches.
Try this and I’ll document it if it works:
sudo chmod -R a+rwX /home/yourusername/shared && sudo chmod 777 -R /home/yourusername/shared
The enhanced permissions also do not facilitate two-way writing in the shared folder.
Indeed, I have been looking at SELinux and I’m already feeling the pains.
I should also note the the above noted boot failure is relieved by moving the shared folder out of /home. I relocated it to /srv (disable-selinux-for-kvm-share-folder) and the boot failure resolves. Just for the hell of it I reverted again to /home and it fails again.
OK try this command on the host instead. It should correct the permissions for the shared folder only so your libvirt-qemu process can access it:
sudo setfacl -R -m u:libvirt-qemu:rwx /path-of-the-shared folder
Thanks for your tenacity.
Just to clarify, one should run this new command after following the recommended shared folder set-up instructions?
For a new install, should the following host modification proceed the “new” command or be eliminated?
sudo chown -R yourusername /home/yourusername/shared && sudo chmod 777 -R /home/yourusername/shared
Okay, so despite my questions above, I took a stab at your latest (2017-M04-01-1700) suggestion, on a freshly installed Whonix-KVM running on Fedora 25-KDE. The following error is returned:
setfacl: Option -m: Invalid argument near character 3
Does this error refer to “u:libvirt-qemu”?? The latter does not automatically appear as a Fedora user as it does in, say, Ubuntu, when KVM virtualization is installed.
Based on this fresh install, I should also note that your advice from 2017-M03-21-1811 appears to have had some positive result: the shared folder is now respecting the “read” permission from both the host and guest side; previously that was not even a guaranteed. And, it’s allowing simultaneous write permission from either side, albeit, limiting the write ability on each file to the side (i.e., user) that created the file. Previously, write ability seemed to be strictly limited to which ever side accessed the shared folder first, within the context of a given session. While not ideal, this is definite progress.
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:
- kvm
- libvirt
- qemu
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.
1 Like
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
1 Like
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