I've configured our iMac to use Standard (ie. restricted) user accounts for my kids. Every now and then one will complain because Minecraft presents the attached Minecraft Launcher warning, "Unable to start Minecraft, if you are running from a dmg, please drag to Applications and try again".
And NO! It's not a technical issue! It's a **PERMISSIONS** assumption made by the installer and not catering for multi-user environments.
I realised a long time ago, around version Minecraft 1.7 that the only way I could enable all my boys to play Minecraft in their own user account was to ensure that every file in the /Applications/Minecraft.app folder had full read/write permissions; in Octal: 0777 (directories) 0666 for normal files. That's an absolute NO NO! However, I tolerated it in favour of having to elevate their permissions and to avoid having to reinstall the game every time a different child wanted to play.
I recently installed the updated launcher for Minecraft 1.13/14, BUT it appears there was yet another update to the launcher today. And trawling the folder tree under /Applications/Minecraft.app I see some permissions have been changed back to rwr-
r- (0644) or rwxr-xr-x (0744). Consequently, my two other sons are not able to play the game until I manually change the permissions again...that is until another update screws it up again.
The attached (redacted) log file records how the application itself is trying to write to the Minecraft.app folder, but fails due to lack of permissions. The most relevant line being:
[Error: 2019-07-24 20:56:58.620398: mainOSX.cpp.mm(75)] main executable is not writable: /Applications/Minecraft.app/Contents/MacOS/launcher
Similarly, the long listing shows how in our case USER1 had all the permissions mentioned above, but since the update USER_2_ has overwritten those changes, and reset the permissions. I may try ACLs, but have avoided those.
I think all these issues stem from the assumption players have elevated privileges on the machine (a no, no in today's day and age with malware, etc.), and that the machine functions in single user mode, again incorrect given the approach to separating user accounts with Cloud identities, etc.
I have only experienced this on an Apple system so can't say if the behaviour is similar on Linux.