well, do you get any errors when you launch the app from commandline … ?
it also helps opening a second terminal and running
journalctl -f
so you can see potential errors …
@ogra when you say launch from command line, do you mean just executing swach? When I try that, I get the following:
/snap/swach/12/bin/desktop-launch: line 600: /snap/swach/12/swach/swach: No such file or directory
I’m not typically a Linux user and I am unfamiliar with Snap. All I know is it works if I package as .deb but will not open when I make a Snap. I know you are very busy, but if you were able to take a look at Swach from the Snap store, perhaps you would be able to identify the problem?
I think perhaps I needed to change the executable name. I did and now I get this error:
[5121:0515/164904.180126:FATAL:setuid_sandbox_host.cc(157)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /snap/swach/13/swach/chrome-sandbox is owned by root and has mode 4755. Trace/breakpoint trap (core dumped).
Seems like we need a way to remove SUID? I have the no-sandbox flag on for Electron, so not sure what else to do.
What do I need to do to become a vetted publisher? All of this work could be avoided, and the app should function great, if I was allowed to use the sandbox.
It’s interesting that setting permissions to 4755 seems to be disallowed by the automatic review process:
- found errors in file output: unusual mode 'rwsr-xr-x' for entry './swach/chrome-sandbox'
But the error when running says to set the permissions to 4755:
You need to make sure that /snap/swach/13/swach/chrome-sandbox is owned by root and has mode 4755
Seems like we are stuck here?
@ogra @jdstrand I spent all day debugging this today and decided to give electron-builder a try. It has its own issues and I have to use lxd as a workaround to build the Snap with --destructive-mode so that I can add giblib1 to the stage packages.
Now it seems most of the app is functioning, but I am unable to save a screenshot with scrot. I get this error:
[ERROR] getColor Error: Command failed: /snap/swach/x1/app/resources/app.asar.unpacked/node_modules/electron-color-picker/library/linux/linux-scrot/scrot /run/user/1000/snap.swach/temp-screenshot.png
giblib error: Saving to file /run/user/1000/snap.swach/temp-screenshot.png failed
at ChildProcess.exithandler (child_process.js:308:12)
at ChildProcess.emit (events.js:210:5)
at maybeClose (internal/child_process.js:1021:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:283:5) {
killed: false,
code: 2,
signal: null,
cmd: '/snap/swach/x1/app/resources/app.asar.unpacked/node_modules/electron-color-picker/library/linux/linux-scrot/scrot /run/user/1000/snap.swach/temp-screenshot.png'
I assume I need to somehow give the app permissions to save temporary files like this. This is only saved to get color information from it, and then it is deleted. Is something like this supported or do I have to make my Snap a classic one to get all the permissions?
this is XDG_RUNTIME_DIR … theoretically your app should have full write access to it, do you see any apparmor denials when this happens ?
@ogra is there anything I have to configure to allow scrot to work and save that image file? It doesn’t really say why it cannot save the image, it just says giblib error: Saving to file /run/user/1000/snap.swach/temp-screenshot.png failed.
I think this is the last major hurdle to getting our app working with Snapcraft, and while I am disappointed there seems to be no way to use electron-forge or electron-installer-snap without being a vetted publisher, I am pleased there is a workaround using electron-builder, even though it is very complicated and required a lot of trial and error.
If you could please help me resolve this one remaining issue, I would very much like to write a blog post to help others with this.
your app should normally have write access to XDG_RUNTIME_DIR (which is set to /run/user/1000/snap.swach/ in your case), I’m not sure why you are not …
open a second terminal, run journalctl -f | grep DENIED in it and start your app to see if there are apparmor denials …
@ogra this is what I get as output when I run that:
May 19 07:53:43 rwwagner90-VirtualBox audit[549]: USER_AVC pid=549 uid=103 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/" interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" mask="send" name="org.bluez" pid=3417 label="snap.swach.swach"
May 19 07:53:43 rwwagner90-VirtualBox kernel: audit: type=1107 audit(1589889223.551:78): pid=549 uid=103 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/" interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" mask="send" name="org.bluez" pid=3417 label="snap.swach.swach"
May 19 07:53:44 rwwagner90-VirtualBox dbus-daemon[1358]: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/com/canonical/dbusmenu" interface="org.freedesktop.DBus.Properties" member="GetAll" name=":1.12" mask="receive" pid=3417 label="snap.swach.swach" peer_pid=1527 peer_label="unconfined"
May 19 07:53:44 rwwagner90-VirtualBox dbus-daemon[1358]: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/com/canonical/dbusmenu" interface="com.canonical.dbusmenu" member="AboutToShow" name=":1.12" mask="receive" pid=3417 label="snap.swach.swach" peer_pid=1527 peer_label="unconfined"
May 19 07:53:44 rwwagner90-VirtualBox dbus-daemon[1358]: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/com/canonical/dbusmenu" interface="com.canonical.dbusmenu" member="GetLayout" name=":1.12" mask="receive" pid=3417 label="snap.swach.swach" peer_pid=1527 peer_label="unconfined"
well, that doesn’t show anything related to saving a screenshot …
if you did that action while capturing the log, I’m out of ideas …
i have never used the electron-installer-snap and my personal electron-builder attempts were unsuccessful too, which made me switch to a proper snapcraft.yaml using electron-packager (like you can see in the post above where i pointed to one of my apps on github). i’m not sure what the tool you are using does to prevent you from writing to XDG_RUNTIME_DIR …
@ogra If it were not an Electron app, what would we be looking for when this issue happens? I’ve switched to electron-builder on the advice in this thread, which did get the app running, but we need to be able to use the color picker, which uses scrot to take screenshots. Are there any interfaces we should be making sure to add or tweaks to permissions we can make somehow? These tools just create a snapcraft.yml behind the scenes, so it should work if we can ensure the correct settings are there.
Is it possible to please become a vetted developer? Since the .deb package works with no problems, I feel that if I were allowed to be a vetted developer, I could basically publish the same package. I do the signing and notarizing processes for MacOS and Windows with no issues, but there doesn’t seem to be a way to register a company as a trusted Snap developer, is there?
interfaces only help where you see denials in your log output … there was none for your secreenshot issue …
well, these generated snapcraft.yaml’s are as generic as possible so fine tuning or tweaks for specific features you add on top of the generic generation are hard to do (as you noticed). These tools are typically fine for general purpose (show a website and some basics) but electron has a gazillion of possible modules you can add with tons of different features that such a generator simply can not cover.
I’m not sure what you want to achieve by becoming a vetted publisher (and i’m not in any team to grant it anyway …)
Yes, but I can put anything you might recommend into the settings to be generated into the snapcraft.yml. The tool is not breaking the app, Snapcraft is making it impossible for scrot to save the screenshot for some reason, and we need a way to determine how to fix that. The problem would exist with or without electron-builder, as when I build for .deb everything works, but does not in Snap, so the issue lies with Snap.
My original build, the one that works as .deb from before the many days of trying workarounds used chrome sandbox, so I needed to be a vetted publisher to do that. It would be very much appreciated if I could become a vetted publisher. I have not found any docs on how to do so, but since it seems impossible to get Snap to allow the correct permissions, it’s worth a shot to become a vetted publisher and see if it works. If not, I may have to try classic confinement next.
I do not understand why .deb works flawlessly and Snap refuses to work, but there has to be a missing setting somewhere, and if we knew how to narrow it down, I could set that setting.
“allow-sandbox: true” is reserved for major browsers like Mozilla Firefox, Brave, Opera, Chrome, etc, not electron apps and as mentioned in this topic, there are many electron apps in the store that do not require it. I suggest creating a new topic in the “snapcraft” category since there will be a lot more people there to help you debug your snap than in the “store-requests” category.
Before you go and do that, since you don’t have any denials related to /run/user/1000/snap.swach/temp-screenshot.png in the logs, that suggests it might be traditional DAC permissions that is causing the problem. Can you:
- make sure that
/run/user/1000/snap.swachexists as an actual directory, not a symlink - if it does, is every directory element in the path owned by your user with (at least) 0700 permissions?
If the answer to all of the above is “yes”, then I suggest you run snap run --strace="-o ./trace" swach and see how it is failing. It is possible that giblib1 is actually having trouble somewhere else (eg, /snap/swach/x1/app/resources/app.asar.unpacked/node_modules/electron-color-picker/library/linux/linux-scrot/scrot is not executable, something else, etc).
Armed with all of that information, if you still aren’t able to figure it out, asking in the ‘snapcraft’ category with this information can hopefully get you the help you need.
FYI, the bluez denials are just noise. The dbusmenu issues shouldn’t be what is causing your trouble but is being discussed in the turbosmtp topic.
This does appear to be a directory and the contents in it are owned by my user.
I tried this, but this is a ton of output in trace. What should I be looking for? I did a grep for giblib and got this:
12450 openat(AT_FDCWD, "/var/lib/snapd/lib/gl/libgiblib.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
12450 openat(AT_FDCWD, "/var/lib/snapd/lib/gl32/libgiblib.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
12450 openat(AT_FDCWD, "/var/lib/snapd/void/libgiblib.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
12450 openat(AT_FDCWD, "/snap/swach/18/lib/libgiblib.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
12450 openat(AT_FDCWD, "/snap/swach/18/usr/lib/libgiblib.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
12450 openat(AT_FDCWD, "/snap/swach/18/lib/x86_64-linux-gnu/libgiblib.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
12450 openat(AT_FDCWD, "/snap/swach/18/usr/lib/x86_64-linux-gnu/libgiblib.so.1", O_RDONLY|O_CLOEXEC) = 10
12450 write(2, "giblib error: ", 14) = 14
12321 read(106, "giblib error: ", 65536) = 14
@jdstrand @ogra I tried running the command directly via command line and it works:
/snap/swach/19/app/resources/app.asar.unpacked/node_modules/electron-color-picker/library/linux/linux-scrot/scrot /run/user/1000/snap.swach/temp-screenshot.png
So I suppose we have some kind of permissions issue when running inside of Snap?
It appears the permissions on scrot are for root:
-rwxr-xr-x 1 root root 27928 May 19 13:46 /snap/swach/19/app/resources/app.asar.unpacked/node_modules/electron-color-picker/library/linux/linux-scrot/scrot
And it appears the run/user/1000/snap.swach where it saves the screenshot has these permissions:
drwx------ 4 rwwagner90 rwwagner90 100 May 19 14:04 snap.swach
Are these compatible? Any ideas here?
Doing it that way, you bypassed all confinement so it doesn’t test that the snap can run it. You will either need to add an apps: entry to your yaml to expose the scrot executable to test whether it is possible to run it directly, or run it through a shell with:
snap run --shell swach /snap/swach/current/app/resources/app.asar.unpacked/node_modules/electron-color-picker/library/linux/linux-scrot/scrot