[Tutorial] Installing a shared folder in your host OS and in your virtual OS

So, I have decided to share with you how I installed my shared folder, as if you follow exactly this Whonix ™ for KVM it could not work.
So in our host OS we are going to run this:

mkdir /home/$USER/shared
chmod 777 /home/$USER/shared

Remember that $USER is your own username of the host OS. Now we can do it in the GUI way or in CLI way.
In the GUI way is the same as in Whonix ™ for KVM
but in the target folder I wrote “/shareddata” instead of “shared”

Alternatively you can run

 virt-xml "Whonix-Workstation" --add-device --filesystem source=home/$USER/shared,target=shareddata,type=mount,accessmode=mapped || true

Remember that if you have changed the name of your virtual machine, “Whonix-Workstation” may vary and you would have to put what you have set up.
Then inside the Whonix-Workstation OS, we are going to run the following (here I did a copy/paste with the output included):

user@host:~$ pwd
/home/user
user@host:~$ mkdir ~/shared
user@host:~$ sudo mount -t 9p -o trans=virtio /shareddata ~/shared
[sudo] password for user:         
user@host:~$

Basically we are mounting our shared folder.
And if you go to the file manager of your workstation, you should find in the section of DEVICES, bellow File System, the shared folder.
The thinks you create inside the whonix-workstation of the shared folder will be in home/$USER/shared
of your host OS, and you may access those files with root privileges.

Please, if you find any security issues, comment bellow, please.

What’s the point of this as opposed to my original steps? it seems risky to expose a device on thh host to an untrusted guest.

If you want the guest to have more control over the permissions of files in the shared folder you simply switch to another mode like “passthrough”

https://lists.gnu.org/archive/html/qemu-devel/2010-05/msg02673.html

Security model : passthrough

In this security model, VirtFS server passes down all requests to the
underlying filesystem. File system objects on the fileserver will be created
with client-user’s credentials. This is done by setting setuid()/setgid()
during creation or ch* after file creation. At the end of create protocol
request, files on the fileserver will be owned by cleint-user’s uid/gid.

I did it because my whonix workstation did not mount automatically the shared folder in the last step:

‘’’
4. Choose the following settings.

Replace user name user with your actual user name.

  • Mode: Mapped [26]
  • Driver: Default
  • Source Path: /home/user/shared
  • Target Path: shared

Click finish. Done.

Whonix-Workstation should automatically find and mount the shared directory once its created and enabled on the Host.
‘’’
So I rewrote the tutorial plus a few steps I did. Probably would be better to make a shared folder inside a usb that is plugged in inside the host OS.
Do you mean to only execute in the last step this command?

sudo mount -o trans=virtio /shareddata ~/shared

instead of this one?

sudo mount -t 9p -o trans=virtio /shareddata ~/shared

This needs to be in the command line

The workstation has a service that automatically mounts the share in the VM. If it’s not working then there’s a bug.

The solution is not to do something dangerous on the host.

1 Like

Ok, probably I modified something of the xml file and that it is why there isn’t working for me in automatic mode, but then I do it manual every time I log in.
I quit this for me to work:
< blkiotune>
< weight>250< /weight>
< /blkiotune>
(I put a space so it can show the message)

But now all works perfect

I thought you might find this interesting. I also had this problem were it did not auto-mount, even after a reboot. The /mount/shared folder was there, but it was not linked to the host. The folder settings were gone in the details pane. I shut the machine down and confirmed that the settings were still there. After I turned the machine back on, the folder was working properly. Obviously you may have also reboot/shutdown twice. My point was simply to show that even one reboot isn’t always enough. Sometimes a second shutdown is required. I am glad I didn’t troubleshoot before trying a another power off. It makes me wonder how many times in my life I wasted time troubleshooting something that simply required another reboot…

1 Like