Multiple shared directories?

[yllekz]

Hi folks,
I'm looking to migrate away from the ever-buggier macOS Docker Desktop to a traditional Debian VM in UTM, but to do this I need the ability to mount multiple shared folders from the host into the guest VM, and currently I'm not sure if that's possible.

I'm wrapping my head around UTM shared directories. I just successfully got one working inside a Debian VM via WebDAV and mounting, but I noticed that it appears that UTM only allows for one shared directory to be mounted to a VM. I tried using symlinks but that basically doesn't work and was a dumb idea anyway. VirtualBox lets you mount a near-unlimited amount of shared folders to a VM, so I was wondering if a) it was possible in UTM, and b) if it is possible, how does one do it?

[redthing1]

This is the sole reason I switched to Parallels

[maartenSXM]

I am not sure about WebDAV but Virtfs allows additional shares. However, to do it you have to manually add a QEMU argument line per share - with each share getting a unique id and a unique mount tag.

With the guest off, go to UTM->settings->QEMU->arguments and scroll to the end of the arguments list. Then, for each additional share click 'New' to create a new argument line and adapt this to your mount path and specify a unique id (the same unique id goes in both places in the argument line) and specify a unique mount tag:
-fsdev local,id=virtfs2,path=/Volumes/extSeagate,security_model=mapped-xattr -device virtio-9p-pci,fsdev=virtfs2,mount_tag=share2

Note that in order to save your new argument line, UTM requires that you to press your <enter/return> key after adding the argument line and then only afterwards can you click the save button and have your new argument line saved.

If you want your added shares auto-mounted in a Linux guest, add lines similar to this to the guest /etc/fstab and create the guest mount paths:
share /mnt/extSamsung 9p trans=virtio,version=9p2000.L 0 0
share2 /mnt/extSeagate 9p trans=virtio,version=9p2000.L 0 0

That first fstab line is there to auto-mount the share configured from the settings->sharing dialog. The second fstab line is for an additional Virtfs share that is added manually to the QEMU arguments, as above. After adding those lines to fstab and creating the mount paths (e.g. mkdir /mnt/extSamsung /mnt/extSeagate), you will need to either reboot or issue these shell commands:
sudo mount /mnt/extSamsung
sudo mount /mnt/extSeagate

[kstlouis]

I've tried this, but the VM won't start up; I see "cannot initialize fsdev 'virtfs2': failed to open '/Volumes/temp_disk': Operation not permitted" when I go back in to edit the config

[gkostov]

I'm having the same issue but there is a workaround for me (not a nice one but it does the job). I'm having a few shared paths of which path1 is on the "Shared directory" setting and the others (say path2 and path3) are additional -fsdev arguments lines. When I first started the machine it complained about "Operation not permitted" on path2. I then selected path2 for the "Shared directory" option and tried a start - it then complained about path3. I selected path3 for "Shared directory" and the machine booted. But of course I did not have path1 now. So I shut it down and selected path1 on "Shared directory". Started the machine and all paths were there and working fine. It felt like QEMU or UTM needed to "get to know" the paths first by setting them on "Shared directory". The machine now starts and stops every time ... unless you leave it shut down for some time or you quit UTM. After that you need to "familiarize" it with the shared paths again by selecting them one by one and only then start the machine. I'm still trying to find out how much time it takes to "forget" the paths but it is more than 15 minutes on my machine (UTM 4.6.2, OS 14.7 Arm)

Cheers

[naveenrajm7]

Thank you for sharing your experience and the workaround.
I had a very similar experience with a different use case.

I guess this has to do with UTM/MacOS, UTM being a sandbox application cannot access files outside of its app sandbox unless you bookmark it (Apple's way of secure access) .
So when you choose the path in 'Shared directory' , UTM will create a bookmark for it before passing it to the qemu, that is why there is no issue for the path used by 'Shared directory'.

UTM Source code snippet for changing 'Shared directory'

func changeSharedDirectory(to url: URL) async throws {
    await clearSharedDirectory()
    let isScopedAccess = url.startAccessingSecurityScopedResource()
    defer {
        if isScopedAccess {
            url.stopAccessingSecurityScopedResource()
        }
    }
    ...

These bookmarks which are associated with specific paths will stay until the defer is called, that is why you can access these paths later without passing them through UTM, until UTM loses bookmark to it.

In our UTM plugin I am trying add directory sharing feature and help simply this process, so we need to come up with a clever idea to workaround this.

Trying to make it as simple as this

Vagrant.configure("2") do |config|
  config.vm.box = "utm/ubuntu-24.04"
  config.vm.synced_folder "/host/path1", "/guest/path1"
  config.vm.synced_folder "/host/path2", "/guest/path2"
end

[EmmJSee]

I’m aware that this post is over a year old…but hopefully not too old.

I’m running UTM on an M2, with a Ubuntu Apple silicon guest. It runs really well, and with GPU pass through. I’ve installed this setup as the Apple ports of Darktable don’t have Metal support, so no GPU! That’s painfully slow!

I’ve successfully shared a folder using this technique. However, when I attempt to add more shares, they are not saved. I have followed these steps; adding paths to the QEMU arguments.

I would like to allow read/write sharing to folders & files within the root of this share, but I don’t want to change ownership of the files.

Should I specify the root of the share in the UI, and then add specific paths in /etc/fstab?

Any help appreciated

[maartenSXM]

Note that you have to hit return after adding the line and the click save after that. Otherwise the line is not saved.