The shared folder is correctly mounted on the guest. If I copy files in the shared folder on host, I am able to open or move it on guest. So far so good. But when I copy files in the shared folder on guest and want to open or copy/move it on the host, I get permission problems. I am not permitted to read/copy/move files out of the shared folder on my host.
So I am able to transfer files from the host into the guest, but not able to transfer files out of the guest to the host. Would be really great If you could help me.Thank you very much!
I’m experiencing a complete inability to access a shared directory with Whonix 13 running on KVM in Fedora 25 KDE spin. I’ve configured following the directions on the KVM page, including the chown & chmod to the host directory. I completely uninstalled and reinstalled KVM and Whonix a second time and run into the same issue.
Upon boot of Workstation (which runs fine) I see a red FAIL error: “Failed to start Mounts KVM shared folder during startup.”
OK. Is Ubuntu a reasonable option? I note that KVM on Ubuntu creates Libvirt Qemu user account that appears on login … Is that normal / acceptable? Thanks.
Actually the shared folder helper package in Whonix 13 was accidentally reverted to an older non-working version. Until Whonix 14 you will need to bite the bullet and run the shared folder mount command manually.
Which means if the shared folder is not enabled in the virtualizer settings, the systemd unit is considered failed, which causes an systemd error message for that systemd unit file at boot, which is a usability issue only. If the shared folder is enabled in the virtualizer settings, it should work?
I think we mean different things. What I’m running into is it fails to mount the shared folder automatically despite being enabled in a VM’s settings. Is this a new bug? (This didn’t happen with Whonix 12)
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.
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
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.
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.
