Could you share your snap and what commands to use with it to reproduce?
Note that this may be because the mount is created in the snap’s mount namespace and not in the host namespace. Are you running mounts from inside the snap’s mount namespace?
Well, the snap itself wouldn’t be too bad to recreate, but this also uses Multipass in order to work, and currently, I just have hacked up versions of both the sshfs snap and multipass just to try to make this work.
Probably, but how do I tell? Also, is there a way to run mounts outside of the namespace?
You can enter the snap’s mount namespace with snap run --shell $SNAP_NAME.$SNAP_APP and running mount or possibly cat /proc/self/mountinfo. Note that if the snap isn’t in devmode, it would need mount-observe connected.
If you are just running mount in a default shell, you will be running in the initial host mount namespace of your system, which the snap mount namespace inherits from, but doesn’t propogate backwards. Said another way, mounts performed in the snap’s mount namespace (generally) don’t propogate back to the initial host mount namespace. I imagine that the mount probably succeeded, indeed the apparmor ALLOWED message implies as much, but since the mount was performed in the snap’s mount namespace you won’t see any of those mounts from the host filesystem outside of the snap.
Yep, that’s what’s going on. I can see the mount after doing snap run --shell sshfs. So I think when it was strictly confined, this was the case too.
So I’m a little confused…I need to run mount outside of the snap, yet the snap has all of the information on how to do the mount. I’m not sure how to accomplish that.
Thanks for all of your help on this!
So it sounds like what you are trying to do is build a snap which can execute mounts which modify the host filesystem outside of the snap, correct? To my knowledge, this would be a new use case which hasn’t been explored much in terms of strict confinement because it explicitly is mounting things outside of the snap, and thus could probably do all sorts of dangerous operations to the system.
Also to be clear, this is not actually a part of Multipass, but rather would be going into a separate snap that would be installed inside an Ubuntu Core VM that Multipass manages, correct?
I think that the next step is that you should start a forum topic in the snapd category and ping @zyga-snapd and @jdstrand about the feature you need.
Yes, that is correct. Or have some way to “present” the mount to the user such that they can go `cd my_host_share" and then the directory on the host that they mounted shows up in the VM.
No, it’s not a direct part of Multipass. It will be side-loaded by Multipass on instance launch and used by any instance that is launched, be it Core, Bionic, Fedora, etc.
I’ll see about posting the new forum topic about how we can accomplish what I need.
Thanks again!
Right but just for clarity this is going both ways - outside of the VM, the user wants to choose what directory is the source mount on the host, as well as inside the VM, the snap needs to create the destination mount in the VM. Just an FYI, it will probably come up as a question if it makes sense to restrict the locations of these mounts (both inside and outside) to the home + removable-media directories
NOTE: The way the mount namespace is created the only place you can mount something (as a snap) and see it visible in the host is /media. Everything else has slave mount sharing and will be only visible to the snap application that has mounted this.
As an example of how this works you can use the gdisk snap on a core device. At present it is also impossible to change the set of directories that have this special property due to how complex it is setting it up.
Yes this is why I was saying it’s a new use case that needs design and implementation because they would need to create arbitrary mounts beyond /media which propogate back out to the host mount namespace.
I think I’ve found another way to do this and will try that.
Thanks for all of the feedback and help!