`multipass umount` a folder within VM "home"

[finalyards]

Problem

While it's easy to mount a folder to Multipass VM default user's home, it's not as easy to umount it.

How I initially experienced this was an "asymmetry" in the UX. If I don't need to specify /home/ubuntu when mounting a folder there, why do I need to specify it for umounting said folder.

$ multipass mount --type=native abc rust:

..but:

$ multipass umount rust:/home/ubuntu/abc

I needed to rewrite the issue 3 times, learning more while testing things out. So bare with me, and let's see if you agree something could be improved... :)

Prelude

There are three ways a folder can be mounted, in Multipass:

	command	VM target
default	multipass mount abc rust:	/home/ubuntu/abc
relative	multipass mount def rust:def	(/home/ubuntu/)def
absolute	multipass mount fgh rust:/fgh	/fgh

Note: Calling these ”default”, ”relative” and ”absolute” are just terms I coughed up.

$ mp info rust
[…]
Mounts:         /Users/xxx/Git/abc => /home/ubuntu/abc
                    UID map: 501:default
                    GID map: 20:default
                /Users/xxx/Git/def => def
                    UID map: 501:default
                    GID map: 20:default
                /Users/xxx/Git/fgh => /fgh
                    UID map: 501:default
                    GID map: 20:default

If the "default" mount were the same as "relative" (currently it's "absolute"), I could:

$ multipass umount rust:abc

..this issue would never have arisen!

Note: This alone would be a breaking change. Scripts might make multipass umount /home/ubuntu/abc, which no longer works (Multipass currently treats "relative" and "absolute" mount completely separate; we'll come to that). But if these were also fused together (a good thing), there would be no breakage.

Side quest

What I'm really trying to do is reduce the surprises in Multipass CLI work.

Unfortunately, I stumbled on another one, which researching this. Seems I can:

$ multipass mount --type native abc rust:abc
$ multipass mount --type native abc2 rust:/home/ubuntu/abc

Both the VM targets are obviously the same, only provided in different ways. If you otherwise try to mount to an already mounted target, it fails:

$ mp mount --type native klm rust:/home/ubuntu/abc
mount failed: The following errors occurred:
"/home/ubuntu/abc" is already mounted in 'rust'

I think the same error should occur, also above (always testing "relative" mount as /home/ubuntu/{..path..}).

Suggestions

1. Change "default" mount to be "relative"

$ mp mount type native abc rust:

When I do this, it should be listed as:

- Mounts:         /Users/xxx/Git/abc => /home/ubuntu/abc
+ Mounts:         /Users/xxx/Git/abc => abc

2. Fuse checks of "relative" and "absolute" mounts together

This means e.g. that:

• mounting as /home/ubuntu/abc, then umounting as mere abc would work (currently does not)
• double mounting would no longer be possible (see above)

Note: This becomes the real thing of the PR, leaving "1" (above) to be merely a cosmetic thing about the mount listing printout.

One could argue that, for consistency, any folder mounted within the VM home folder (/home/ubuntu) could be listed in the "short format". Or... the opposite: mounts would always be listed with their absolute path.

Whichever way this goes, I think the Multipass mount system would be less surprising, if such changes to it are made.

Work-around

I might, with a sigh, stop using the multipass mount [...] abc rust: short-hand, and always append the target folder name. This way, I don't need to remember to add the full path when umounting.

---

macOS 15.7.3 (Intel)
Multipass 1.16.1

[xmkg]

Hi @finalyards, thanks for sharing your experience and insight! I've tried to reproduce the problem from the detailed steps you've posted, and it behaves as you described in 1.16.1. However, the behavior has changed in the latest edge build, and now all three ways of mounting you mentioned (default, relative, absolute) resolve to absolute paths:

multipass mount --type native docs engaged-barbel:abc
multipass mount --type native docs engaged-barbel:/home/ubuntu/def
multipass mount --type native docs engaged-barbel:

Before (v1.16.1):

❯ multipass info
Name:           engaged-barbel
State:          Stopped
Snapshots:      0
IPv4:           --
Release:        --
Image hash:     2b5f90ffe818 (Ubuntu 24.04 LTS)
CPU(s):         --
Load:           --
Disk usage:     --
Memory usage:   --
Mounts:         /workspace/multipass/docs => /home/ubuntu/docs
                    UID map: 1000:default
                    GID map: 1000:default
                /workspace/multipass/docs => /home/ubuntu/def
                    UID map: 1000:default
                    GID map: 1000:default
                /workspace/multipass/docs => abc
                    UID map: 1000:default
                    GID map: 1000:default

After (edge):

❯ multipass info
Name:           resolute-flycatcher
State:          Stopped
Snapshots:      0
IPv4:           --
Release:        --
Image hash:     2b5f90ffe818 (Ubuntu 24.04 LTS)
CPU(s):         --
Load:           --
Disk usage:     --
Memory usage:   --
Mounts:         /workspace/multipass/docs => /home/ubuntu/docs
                    UID map: 1000:default
                    GID map: 1000:default
                /workspace/multipass/docs => /home/ubuntu/def
                    UID map: 1000:default
                    GID map: 1000:default
                /workspace/multipass/docs => /home/ubuntu/abc
                    UID map: 1000:default
                    GID map: 1000:default

While I understand this is quite the opposite of what you want, the edge build now at least has consistency on how the mount targets are normalized so it's possible to treat all the same regardless of the initial way of mount (relative/absolute).

For the side-quest part, I could reproduce it in the 1.16.1, but could not reproduce it in the latest edge build, so it seems like we already fixed that bug. That fix would be in the 1.17 release.

[finalyards]

@xmkg Sounds great!

Should I close the issue now, of after 1.17 is out?