I am in a situation where a snap package has to access files which are stored on a remote file system share (mounted at “/nfs”). I see there is currently no “clean” way to achieve this. For some time, I could help myself with “bind” mounting stuff below the “/media” folder, that would enable access. For some reason this has stopped working reliably. I typically get this error when starting my application:
“cannot open path of the current working directory: Permission denied”
My snap package is currently in devmode. This is both what is defined in snapcraft.yaml and during snap install, which I do with “–dangerous --devmode” options.
…and to me this implies that my package should be able to access the filesystem. What am I doing wrong?
Note that “classic” confinement is not an option for me, because I cannot have non-snapped shared libraries interfere with it. Currently for me, the point for snap is more the “run everywhere” part, and I am not concerned so much about security.
You should try installing with just--devmode, not both --dangerous and --devmode as --dangerous turns on confinement and --devmode is supposed to turn it off, so it seems that we should probably add some code to make snap install “do what you mean” and use the --devmode confinement being off to overwrite the --dangerous leaving it on.
Also to be clear,
snap install ... --dangerous installs with confinement turned on, but with the check for a matching snap-declaration turned off. The snap-declaration is what contains things like the revision number, any auto-connects you might have, etc.
snap install ... --devmode installs with confinement turned off (well in “complain” mode mostly), but also with the check for a matching snap-declaration turned off.
I think the error here is that when --dangerous and --devmode are used together, --devmode should “win” and apply instead of --dangerous. Then the help messages and the expected flow makes the most sense.