[HOME] [DOWNLOAD] [DOCS] [BLOG] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

Problems with File-Sharing between Host and Guest


#1

Hi folks!

Using Debian as host and Whonix with KVM as guest. Did the following steps:

http://kkkkkkkkkk63ava6.onion/wiki/KVM#Shared_Folders

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!


#2

To freely move and edit the files on the host again you need to run:

sudo chown -R yourusername /home/yourusername/shared && sudo chmod 777 -R /home/yourusername/shared

to readjust permissions (as mentioned in the wiki). Have you tried that?


#3

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.”

Any other suggestions?


#4

That’s because SELinux is being a bitch and my only suggestion to you is to move to a major distro with Apparmor support like Debian.


#5

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.


#6

No. To understand why please see:


#7

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.

http://www.linux-kvm.org/page/9p_virtio

sudo mount -t 9p -o trans=virtio,version=9p2000.L shared /mnt/shared


#8

The only bug is in /lib/systemd/system/mnt-shared-kvm.service and a minor one.

https://github.com/Whonix/shared-folder-help/blob/Whonix13/lib/systemd/system/mnt-shared-kvm.service

ExecStart=/bin/mount -t 9p -o trans=virtio shared /mnt/shared -oversion=9p2000.L || true

https://github.com/Whonix/shared-folder-help/blob/Whonix13/lib/systemd/system/mnt-shared-kvm.service

ExecStart=/bin/bash -c '/bin/mount -t 9p -o trans=virtio shared /mnt/shared -oversion=9p2000.L || true'

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?


#9

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)


#10

Why doesn’t it work?

systemctl status …

Can you try the systemd unit file from shared-folder-help git master please?


#11

Confirmed. The version in master works :slight_smile:


#12

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!


#13

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.


#14

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?


#15

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


#16

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


#17

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.


#18

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


#19

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

#20

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.