Question about mount(2)

[wjk]

One of the things I see Snap packages can do is mount or unmount SMB/CIFS shares. That led me to thinking: how would the user mount a filesystem in Ubuntu Core Desktop? From what I can tell the mount binaries are not in the base image. Even if there were there, there would be no terminal in the final image to use them from.

If I were to provide them in a snap with a GUI, I would run into severe problems with where I can mount a share due to strict confinement, because it would have to be under either $SNAP_USER_COMMON or $SNAP_USER_DATA. This to me is not a very user-friendly location to store what is effectively document data. If I were to use the portals to mount it elsewhere, then I would need to use the portal a second time to unmount it (causing a paper cut that users might complain about). And there seems to be no way to have the system open a folder to the user in their file manager (allowing them to access the location that way), which is an API Windows and macOS both provide.

Furthermore, wouldn’t I still need to be root to successfully call mount(2)? Fixing this through use of sudo requires the terminal, and probably wouldn’t be allowed on the Snap Store in the first place.

How am I supposed to take advantage of the cifs-mount interface given all that I have explained above?

[kenvandine]

This is something that we're going to need to spend some time on. You are right, typically this is something that should be usable without the need for a terminal. Ideally we should leverage the portal infrastructure, but there are likely some rough edges there that will need to be addressed.

Leveraging the portal would allow it to be mounted in a location that's easily accessed from common tools, like nautilus and file pickers in other applications.

[wjk]

One update to this conversation. Everything I said about $SNAP_USER_COMMON or $SNAP_USER_DATA above is actually false. After inspecting the portal API documentation, I see there is a persistent parameter that works very well here. Still don’t know what to say about the root requirement, though.