Hi @emitorino,
Thank you for your response and the reminder (I had already started with an answer, but wanted to test further to make sure that mount_control is not an option - I apologize for my late response.).
I’ve been trying for many hours now to see if I could get it to work with mount_control, but I just didn’t have any luck. It seems to me that even with this it is not possible to get a nested mount.
To test mount_control, I’ve modified my appropriate snapcraft.yaml to this:
name: zffmount
adopt-info: zffmount
summary: Tool to fuse-mount zff files.
description: |
<omitted> base: core20
confinement: strict
parts:
zffmount:
build-packages: [ gcc, fuse, libfuse-dev, pkg-config ]
stage-packages: [ fuse ]
plugin: rust
source: .
override-pull: |
snapcraftctl pull
VERSION=“$(git describe --tags --abbrev=0)”
[ -n “$(echo $VERSION)” ] && GRADE=stable
snapcraftctl set-version “$VERSION”
snapcraftctl set-grade “$GRADE”
override-stage: |
snapcraftctl stage
chmod u+s bin/fusermount
plugs:
mntctl:
interface: mount-control
namespace: host
mount:
- what: /**
where: /**
type: [ fuse ]
options: [ rw, async, ro ]
apps:
zffmount:
command: bin/zffmount
plugs: [mntctl, fuse-support]
architectures:
- build-on: [ amd64 ]
But it doesn’t work.
Still, I see
zffmountis successfully published under strict confinement, and it is indeed actively consumed from the snap store. So can we say classic is not needed any more?
However, the published zffmount package under strict confinement is not working as expected. 
That’s indeed a very valid point, since as per our process for granting classic confinement, that’s a requirement.
There are programs that are exclusively designed to deliver content from specific file formats using FUSE. For such programs, a separate category would be really desirable. zffmount is such a program.
Thanks,
ph0llux