[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

Issue creating shared directory between host and guest

KVM
#1

Issue: Issue creating shared directory between host and guest
I was following the steps on how to create a shared directory between host and guest VM from this article(https://www.explorelinux.com/how-to-create-shared-directory-between-host-and-guest-in-kvm/)
I didn’t get very far.

Initial condition:

shutdown whonix gateway and workstation

In host OS:

$ mkdir /home/(hostuser)/vmhost-share
$ sudo chown libvirt-qemu:libvirt-qemu /home/(hostuser)/vmhost-share

$ ls -ld vmhost-share
drwxrwxrwx 2 libvirt-qemu libvirt-qemu 4096 Mar  6 19:42 vmhost-share

open virt-manager
select “show vm hardware details”
click “add hardware”
select “file system”
type=mount
driver=squash
sourcepath=/home/(hostuser)/vmhost-share
targetpath=/vmshare

Start whonix gateway…ok
start whonix workstation…failed

whonix workstation console output…

$ sudo virsh start Whonix-Workstation
error: Failed to start domain Whonix-Workstation
error: internal error: qemu unexpectedly closed the monitor: 2021-03-08T15:31:51.184081Z qemu-system-x86_64: -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=/vmshare,bus=pci.0,addr=0x8: cannot initialize fsdev 'fsdev-fs0': failed to open '/home/(hostuser)/vmhost-share': Permission denied
[Help Welcome] KVM Development - staying the course
How to enable KVM shared folders from cli
#2

Please follow the instructions documented here instead of trying something on your own:

#3

I followed the instructions of the document you provided. It still doesn’t work.

Here are the steps…

Initial condition:

Both whonix gateway and workstation are running

Configuration:

open virt-manager

select whonix workstation
select “show vm hardware details”
click “add hardware”
select “file system”
type=mount
driver=default
mode=mapped
sourcepath=/home/samplehostuser/shared
targetpath=shared
click “apply” button

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

click “yes”.

Shutdown and start workstation

Shutdown whonix workstation
start whonix workstation…fails

$ sudo virsh start Whonix-Workstation
error: Failed to start domain Whonix-Workstation
error: internal error: process exited while connecting to monitor: 2021-03-08T19:10:13.527737Z qemu-system-x86_64: -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=shared,bus=pci.0,addr=0x8: cannot initialize fsdev 'fsdev-fs0': failed to open '/home/samplehostuser/shared': Permission denied

$ ls -l -d shared
drwxrwxrwx 2 samplehostuser samplehostuser 4.0K Mar  8 11:43 shared/
#4

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.
#5

Did you add your user to the libvirt and kvm groups? I also assume you’ve chowned the shared dir

#6

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

Any more suggestions?

#7

What host are you using? I’m guessing something other than Debian stable. I would file a bug report with them at his point.

#8

syntax:

sudo -u user-which-you-think-will-be-creating-files touch /path/to/folder/example-file
sudo -u user-which-you-think-will-be-creating-files rm /path/to/folder/example-file

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

  • Stay out of /home-anything.

Running under user user:

$ mkdir afolder
$ sudo chown user2:user2 afolder
$ sudo -u user2 touch /home/user/afolder/test

touch: cannot touch ‘/home/user/afolder/test’: Permission denied

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

#9 
$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.2 LTS
Release:	20.04
Codename:	focal
#10
#11

I finally got it to work.

Scenario#1: This works

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:

  1. /home/samplehostuser permission is 777 or
  2. 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 (https://www.whonix.org/wiki/KVM#Shared_Folders) is not clear on this and needs to be updated with these details

#12

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.

#13

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

#14

Insecure because then any limited linux user account can read that folder.

Better.

770 means ug+rwx. Owner and group having read, write, execute permission. The execute permission seems not needed.

Could you try 660 please?

660 means ug+rw. Owner and group having read, write permission.

Even worse than #1.

What’s the issue with #2?

That should also be avoided. No need for user libvirt-qemu to have full access to whole home folder of samplehostuser.

#15

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

#16

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.

1 Like
#17

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
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]