Insync crashes when opening the GUI on Linux (Arch)

I have an issue that is very similar to an issue that has already been discussed here in other threads, but the details are different and the solution suggested in other threads does not work for me.

The problem is that Insync crashes the moment I try to open the GUI. The application starts in the background when I boot my machine and runs fine, but once I try to open the GUI, it’s gone.

The solution (or workaround) suggested in, e.g., the thread here is to remove or rename /usr/lib/insync/, but that has already been done by the package and so doesn’t solve the issue for me.

When I start insync from the command line with --no-daemon, I get the following messages:

joost@p200300d6270da53a9c66dfc5612e95b7 ~$ insync start --no-daemon
libGL error: MESA-LOADER: failed to open iris: /usr/lib/ undefined symbol: drmCloseBufferHandle (search paths /usr/lib/dri, suffix _dri)
libGL error: failed to load driver: iris
libGL error: MESA-LOADER: failed to open iris: /usr/lib/ undefined symbol: drmCloseBufferHandle (search paths /usr/lib/dri, suffix _dri)
libGL error: failed to load driver: iris
libGL error: MESA-LOADER: failed to open swrast: /usr/lib/ undefined symbol: drmCloseBufferHandle (search paths /usr/lib/dri, suffix _dri)
libGL error: failed to load driver: swrast

Note that these are the same files that the OP of the thread linked above reported, but the error is different: “undefined symbol” vs. “cannot open shared object file: no such file or directory”. Of course, I don’t know if these messages have anything to do with my issue, but they’re there.

Insync nonetheless runs fine, until I try to open the GUI: at that point, it crashes with the following error:

Failed to create OpenGL context for format QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile) 
Fatal Python error: Aborted                                

I’m on Arch Linux, the Insync version is 3.8.3. There’s no official Arch package for Insync, but there’s a community-provided one, which basically just takes the .deb and repackages it, with some Arch-specific workarounds (of which renaming /usr/lib/insync/ is one, like I said). Details can be found here:

I suspect it’s either a missing library or a version mismatch somewhere, but I haven’t been able to find anything. Any help would be appreciated.



Hello, @permafrosty! Thanks very much for sending a detailed walk through of the issue.

I’ve already escalated this to our Linux team for advise; I’ll let you know here if we need more information aside from what you’ve already provided.

Thank you!

1 Like

I’m running the same version under Arch Linux without problems. If you have not done this already, I’d recommend doing a full removal of insync and then installing again.


1 Like

Thanks @Brackenhill_Mob, that gives me hope that the issue can at least be resolved. I did do a full removal and reinstall, but the problem persisted. Are you running Gnome (I am) or some other environment? Wayland or Xorg?

Perhaps some more useful information: I’m running Gnome on Xorg. If I switch to Wayland and start with insync start --no-daemon I get the warning “Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.” I still cannot open the GUI.

But if I start insync with:

QT_QPA_PLATFORM=wayland insync start --no-daemon

Insync starts up and I can open the GUI, however the window has no window decorations (no title bar, no maximize/minimize/close controls), so I can’t actually close the window…

I’m running Cinnamon under Wayland

I’m also running EndeavourOS (arch variant) with XFCE and Cinnamon on a couple of laptops and both work fine.

Forgot to flag @permafrosty for those last 2 replies!

Hi @permafrosty,

We’ll look into the issue when running an Xorg session.

As for running Insync on Wayland, here’s a suggested workaround:

Please scroll to this section:

Apparently there’s no need to flag me, I got notifications for your replies. Thanks for those, BTW, hopefully it helps the Linux team figure out what could be wrong.

I installed Cinnamon myself to see if that changes things, but it doesn’t. Insync still crashes as soon as I try to open the UI.

I’m running KDE Plasma/XOrg/Arch and seeing the same issue with app_version=


Hello, @Steve_Schatz! I’ll have our Linux team investigate this.

Could you let me know if the same issue happens when you run a Wayland session?

For another datapoint, I’m also using KDE Plasma/XOrg/Arch with insync but without any problems. I wonder if there’s a particular configuration or missing package that causes a problem.

If I switch to a Plasma-Wayland session I am able to run the Insync GUI.

I should qualify this - since I had reloaded Insync and deleted my old config, when Insync started under Wayland the GUI ran and allowed me to re-setup my account. However when I exited and tried to restart the GUI, it would not load but Insync did not crash. I don’t use Wayland at all and I noticed several other issues, so I probably have lots of things misconfigured for Wayland.


1 Like

Looked into this a little more today. My version has been updated to since I last posted but the GUI still crashes. I saw that I was getting some gl/mesa/drm errors. In my insync directory I renamed to and now the GUI app runs fine.

1 Like

It seems renaming works for me as well. I have the same insync version and I can run the GUI now, too.

1 Like

Thank you for cross-posting here @Steve_Schatz! And glad to hear it’s working for you too, @permafrosty!

It seems that this problem is simply caused by not clearing out the build directory before upgrading to a new version. Files that were part of previous versions remain in the build directory and are put in the resulting package, even though they shouldn’t be there.

One should therefore always run makepkg --clean before upgrading.

1 Like