@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.