ipfs-desktop app is published at: Install ipfs-desktop on Linux | Snap Store
(this is the GUI version of https://snapcraft.io/ipfs, aimed at less technical Desktop users)
As with go-ipfs versions, users report multiple issues related to Snap confinement.
Some examples (new user, so can’t post real links…):
In general, user should be able to read any file in the system to do ipfs add myfile.txt (similar use case as in ipfs-cluster which was already approved in here) and maintain the same config and repo across upgrades.
To fix ipfs-dektop for Snap users we want to switch https://github.com/ipfs/ipfs-desktop/blob/3b138478835117469a4dcd89fca59e3fb25e5e18/electron-builder.yml#L67 to classic, but my understanding is that we need to get from this manual process first.
Can you please provide more details as to the errors which are seen when ipfs-desktop is run under strict confinement? What operations require classic confinement?
@lidel thanks but unfortunately this is not a valid data-point to argue for the case for classic confinement. Also since snaps are given full control over their own private storage under ~/snap/<snap-name>/<revision> so it may not be snap confinement which is causing this issue. e.g. for a strictly confined snap that doesn’t even plug the home interface it can lock files in it’s own private storage:
$ snap run --shell indicator-sensors
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
amurray@graphene:/home/amurray$ flock snap/indicator-sensors/common/foo -c "ls snap/indicator-sensors/"
291 297 common current
ie running a shell within snap’s confinement I am able to lock a file within the priivate storage.
I wonder in this case perhaps if a snap got refreshed and so this <revision> in your upstream bug report may not be the active revision anymore (ie the user was running say revision 37 and so ~/snap/<snap-name>/current points to ~/snap/<snap-name>/37. Then the snap got refreshed to say 38 and so ~/snap/<snap-name>/current now points to ~/snap/<snap-name>/38 but the snap may still use the old 37 path (or vice-versa)).
If this was the case this should now be avoided as snap refresh awareness is enabled by default IIRC which should stop a snap from refreshing to a new revision whilst it is already running.
Either way, if you could provide more details regarding any AppArmor DENIAL messages or similar which are seen in these cases then we can help try and resolve these issues.
from this manual process first.