Hi,
i am currently working on a snap that makes use of parallel install. The snap also uses a content interface (“spool mode”?, inverse direction). It seems like the content interface is not resolving the path correctly.
IIRC this is correct. /var/snap/my-snap_key is set up to be a bind mount on /var/snap/my-snap. For most applications, even if you hardcoded in /var/snap/my-snap before in your program, running as a parallel installed instance should be completely transparent. See the section about Snap environment, data and namespace in https://snapcraft.io/docs/parallel-installs. Those changes are made before any content mounts are applied.
If you believe that the content is showing up incorrectly, please attac the contents of /var/lib/snapd/mount/snap.<yoursnap>.<yourapp>.fstab, then execute the commands below and attach the output:
$ snap run --shell <snap>.<app>
# inside the snap shell
$ findmnt
I see now what you try to achieve. This is a slightly different use case as you are using the parallel instances of the snap providing the content slot. Can you provide the output of snap connections rexroth-deviceadmin ?
Unfortunately this use case is not supported at the moment. You can safely use a snap with an instance key on the plug side of the content interface connection, but using one on the slot side will produce confusing results, like ones you have observed. In fact, I think we should reject such connection of the content interface until there’s support in place. TBF, I’ve always considered using a parallel instance of a snap on the slot side to be confusing at best and something that should be avoided, supposedly with exception of content interfaces although it’s bit muddy since in theory you can mix content from different instances tracking different channels.
If you can, please file a bug report https://bugs.launchpad.net/snapd/. We have just released 2.49, but maybe we can land something in time for 2.50.
Thanks for your investigation. I will file a bug report on launchpad. For us it is essential to have the 1-plug to n-slots scenario since all snaps share information with the 1-snap on plug side, but the content should not be shared between the others. I have to say that I expected some problems using parallel installs with this scenario, but hopped there is an easy solution.