Following a guide https://snapcraft.io/docs/electron-apps which recommends using electron-builder produces Element snap that fails with the error in .cc file.
[37109:0122/011916.538694:FATAL:platform_shared_memory_region_posix.cc(255)] This is frequently caused by incorrect permissions on /dev/shm. Try 'sudo chmod 1777 /dev/shm' to fix.
I reported the problem on electron-builder GitHub, but it may belong here.
Does not reproduce for me on ubuntu 20.10. Maybe snap folks have an idea why /dev/shm appears to have wrong perms on Fedora? @ijohnson
Are you building the snap natively on Fedora and then also running that snap on Fedora? Does electron-builder standup a container environment based on the base: ... for the generated snapcraft.yaml to run the build in? Otherwise, I would say that natively building strictly confined snaps using an Ubuntu base snap w/o snapcraft on non-Ubuntu platforms is expected to fail in weird ways.
Building the snap in Ubuntu 20.04 docker (podman) container and then running it on Fedora 33. But I asked to run the same snap to person with Ubuntu and he the same error message. The recommended electron-builder produces .snap directly. I don’t know if it runs snapcraft under the hood.
What happens when you run the snap on Ubuntu 20.10? Does the Element GUI successfully start?
Electron builder, by default, actually “cheats” and uses a pre-built snap archive that it injects the application into, then re-packages. Snapcraft is never invoked. So wherever it builds it should nearly be the same thing…
The UI looks the same as natively running the app.
@abitrolly did you try using the quickstart example from the tutorial as well?
I need to rent Ubuntu 20.04 box somewhere to test the error is repeatable there as well. It will take some time.
I’ve just run it in a clean Ubuntu 20.04 VM, I get the same warning, the AppIndicator icon works and clicking it brings up a window but the actual contents don’t render.
Edit:
james@james-Virtual-Machine:~/element-desktop$ snap run --shell element-desktop
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
james@james-Virtual-Machine:/home/james/element-desktop$ ls /dev/ -auxl | grep shm
drwxrwxrwt 2 root root 40 Jan 25 18:42 shm
Edit 2: This might not be a snap specific issue, I’ve found some related issues with Firejail
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968382
I would suggest trying a cloud image and pass -vga virtio -display gtk,gl=on to qemu, should work well enough for typical use cases.
OK, I realize now you linked the built snap and repo in the other link.
I reproduced with your snap on Ubuntu 20.10. I built it myself as well to confirm.
[249977:0126/090616.207115:ERROR:platform_shared_memory_region_posix.cc(250)] Creating shared memory in /dev/shm/.org.chromium.Chromium.vJB8bv failed: Operation not permitted (1)
With the browser-support plug (connected), that should work ?! 
Chromium/Electron has a --disable-dev-shm-usage flag, this eliminates the textual error but doesn’t solve the GUI. Neither does running in devmode, or even transplanting Element into an Electron snap generated with snapcraft with core18 or 20, and the second you run Element in the snap outside of the snap confinement it works absolutely fine, I.E /snap/element-desktop/current/@element-desktop (Actual path might be slightly diffo, I’ve messed around a lot)
The GUI white screen + appindicator happens to me even for native build/run (and don’t get the shm error).
I tried that but with logging enabled (--enable-logging) I see loads of other errors:
[255670:0126/092648.605115:ERROR:command_buffer_proxy_impl.cc(91)] ContextResult::kFatalFailure: AllocateAndMapSharedMemory failed
[255670:0126/092648.605188:ERROR:platform_shared_memory_region_posix.cc(250)] Creating shared memory in /run/user/1000/snap.element-desktop/.org.chromium.Chromium.WBBjqg failed: Operation not permitted (1)
[255670:0126/092648.605225:ERROR:platform_shared_memory_region_posix.cc(253)] Unable to access(W_OK|X_OK) /run/user/1000/snap.element-desktop: Operation not permitted (1)
Note: We’re having the exact same issue with the mattermost-desktop snap: https://github.com/snapcrafters/mattermost-desktop/issues/45
I’m guessing this will affect many snaps as applications move to a newer electron version.
funny, i dont see that in my electron snaps (and many of them are on core20 using electron: latest (14.0.0) in their package.json, specifically mattermost-client-ogra) … though i’m using electron-packager to build them from snapcraft.yaml
So as a casual observation, it’s funny how this doesn’t work
/snap/mattermost-desktop/current/opt/Mattermost/mattermost-desktop --no-sandbox
Why is it funny? Well aside from the fact it basically skips the entirety of the snap sandboxing (and the snap mount namespacing, environment variables, etc but that’s not particularly relevant to the casual observation), it actually has the same error with /dev/shm.
And, just to prove this isn’t a case of “maybe all Electron apps behave like this”, well, try sudo snap install joplin-desktop and then do /snap/joplin-desktop/current/linux-unpacked/joplin --no-sandbox. It actually works.
Curiouser still, try dropping the --disable-sandbox flag.
/snap/mattermost-desktop/current/opt/Mattermost/mattermost-desktop
It actually works.
It’s the presence of the --no-sandbox flag that’s causing problems, not necessarily the snap sandboxing in general (as much that using the priviledged extras of the browser-support interface allows you to drop --no-sandbox).
Given also that the main Node process continues to function, you can use the AppIndicator tray icon, and even open new windows and try make those windows browse websites (causing more errors, but it does actually respond), all from an out of process debug console, I’m suspicious this isn’t actually snap causing the problems, and it’s actually something in Node/Electron itself. It’s literally only the render process having issues.
Edit:
It’s reproducible with the AppImage
wget https://releases.mattermost.com/desktop/4.7.2/mattermost-desktop-4.7.2-linux-x86_64.AppImage
chmod +x mattermost-desktop-4.7.2-linux-x86_64.AppImage
./mattermost-desktop-4.7.2-linux-x86_64.AppImage --no-sandbox
looking at the snapcraft.yaml of mattermost-desktop it is actually using the pre-packaged binaries from the deb … i can not reproduce the behaviour with any of my snapped electron apps here (i.e. mattermost-client-ogra), but they all build from source, my suspicion is that there is something in the deb (or the way it was built) that causes this behavior …