Hey @jnsgruk,

We've been able to reproduce this issue and have identified the cause. It appears that when the home directory (~) is mounted using multipass launch ... --mount ., multipass exec results in SUDO_USER=root, SUDO_UID=0, and SUDO_GID=0 instead of the expected values. However, when the home directory is not mounted, or if a subdirectory inside the home folder is mounted (e.g., ~/tmp instead of ~), the issue does not occur.

Minimal Reproducible Example

This fails (produces incorrect SUDO_ values):

multipass launch noble --disk 50G --memory 4G --cpus 2 --mount . --name juju-dev
multipass exec juju-dev -- sudo env | grep SUDO_

Output:

SUDO_COMMAND=/usr/bin/env
SUDO_USER=root
SUDO_UID=0
SUDO_GID=0

This works (produces expected SUDO_ values):

multipass launch noble --disk 50G --memory 4G --cpus 2 --mount ~/tmp --name juju-dev
multipass exec juju-dev -- sudo env | grep SUDO_

Output:

SUDO_COMMAND=/usr/bin/env
SUDO_USER=ubuntu
SUDO_UID=1000
SUDO_GID=1000

Since concierge relies on SUDO_USER to determine the real user (as noted in concierge issue #37), this behavior in multipass exec is likely causing concierge to run as root instead of ubuntu.

We’re actively investigating the root cause right now, but in the meantime, mounting a subdirectory (e.g., ~/tmp) instead of the entire home folder (~) appears to avoid the issue. Would this workaround be acceptable for concierge’s use case, or does concierge require /home/user to be mounted as a whole?

Concierge itself has no requirement for any mounts 😃

I have that example as it was what was reported by @omar-selo - I'm sure he'll appreciate knowing this workaround while you look into the cause 😃

Thank you!

Thank you for looking into this @levkropp & @jnsgruk.

I've tested the workaround and found that we missed something. Specifically, the issue does not occur when the mounted directory is the home directory. Instead, it occurs when the mounted directory is ., irrelevant of what directory that is. For instance, you can try the following:

1. cd ~
2. mkdir tmp
3. cd tmp
4. multipass launch noble --disk 50G --memory 4G --cpus 2 --mount . --name juju-dev
5. multipass exec juju-dev -- sudo env | grep SUDO_

Which will output:

SUDO_COMMAND=/usr/bin/env
SUDO_USER=root
SUDO_UID=0
SUDO_GID=0

Ah looks like I was wrong. The issue is yet something else. If you run multipass exec juju-dev -- sudo env | grep SUDO_ inside the directory that you mounted or any of the sub-directories, then the issue occurs.

For instance:

1. cd ~
2. mkdir tmp
3. multipass launch noble --disk 50G --memory 4G --cpus 2 --mount tmp --name juju-dev
4. multipass exec juju-dev -- sudo env | grep SUDO_ shows correct result
5. cd tmp
6. multipass exec juju-dev -- sudo env | grep SUDO_ shows incorrect result

Well spotted @omar-selo. So this is being caused by the directory mapping. If I just opt out of that, I don't get the issue any more:

$ multipass mount tmp/ nourished-flamingo
$ cd tmp/
$ multipass exec nourished-flamingo -- sudo env | grep SUDO_
SUDO_COMMAND=/usr/bin/env
SUDO_USER=root
SUDO_UID=0
SUDO_GID=0
$ multipass exec -n nourished-flamingo -- sudo env | grep SUDO_
SUDO_COMMAND=/usr/bin/env
SUDO_USER=ubuntu
SUDO_UID=1000
SUDO_GID=1000