sirs please be professional on this, fedora 30 was released on 30 april and still no fix… you also have ZERO communication with your users… please update at least once a week with progression and/or information about this problem… i am conseidering a change of company…
thanks
Hi everyone,
If you guys aren’t on a VM and are running F30, please try the fix below:
sudo rm /usr/lib/insync/libstdc++.so.6This should get Insync up and running.
I’m so sorry for the lack of updates on this guys. 
Can confirm that the workaround does allow the Insync GUI to load on a Fedora 30 system (non-VM).
najdc’s fix worked for me. Running Fedora 30 baremetal (5.1.6-300.fc30.x86_64).
WORKED nicely.
App started with GUI like before. No more headless!!
Thanks Nikki! Working for me as well after removing “libstdc++.so.6”.
Hi!
Removing libstdc++.so.6 worked for me as well.
I’m seeing a little weirdness in the qt windows though (for example, I can’t seem to save preference changes) but otherwise, insync is back to working.
Bobby
I can confirm that this workaround seems to fix the startup issues.
Although I think it is sad that it took Insync engineers almost two months to come up with this simple solution. Also, there is still no functioning repository for Fedora 30.
I am sorry but this isn’t a solution, I have other binaries which depends on libstdc++.so.6, it can not be removed like that.
Still not a real solution from my point of view guys, I had to restore it to get some other tools working.
The libstdc++ library that Insync have recommended be removed from the Fedora installation is the version of the library that they distribute with the insync client (at /usr/lib/insync/libstdc++.so.6). Deleting this file should not impact your other binaries that depend upon libstdc++ surely? They should be dependent upon the version of libstdc++ located at /lib64/libstdc++.so.6.0.26 (provided by the libsdtc++ RPM package?
If you’ve self-compiled binaries against the libstdc++ distributed by Insync then you should probably change to use the distribution supplied libraries (compiling against a 3rd party [insync in this case] provided libraries is bad practice).
I have the same problem on openSUSE Tumbleweed. I can confirm that deleting the /usr/lib/insync/libstdc++.so.6 library fixes the problem here, too.
However, I have a problem with the Insync repo, which may be similar to the problem other users have reported on Fedora.
Zypper reports that my insync client isn’t the latest one:
~> LANG=C zypper se -s insync Loading repository data...Reading installed packages…
S | Name | Type | Version | Arch | Repository
—±-------------------------±--------±------------------±-------±-----------
v | insync | package | 1.5.7.37371-fc26 | x86_64 | insync repo
v | insync | package | 1.5.5.37367-fc26 | x86_64 | insync repo
i+ | insync | package | 1.5.4.37362-fc26 | x86_64 | insync repo
v | insync | package | 1.5.2.37346-fc25 | x86_64 | insync repo
v | insync | package | 1.4.5.37069-fc25 | x86_64 | insync repo
v | insync | package | 1.4.5.37069-fc25 | i686 | insync repo
| insync-caja | package | 1.3.12.36116-fc17 | noarch | insync repo
i+ | insync-dolphin | package | 1.3.12.36116-fc17 | noarch | insync repo
v | insync-dolphin | package | 1.3.8.36087-fc17 | noarch | insync repo
| insync-headless | package | 1.5.7.37371-fc26 | x86_64 | insync repo
| insync-headless | package | 1.5.5.37367-fc26 | x86_64 | insync repo
| insync-headless | package | 1.5.4.37362-fc26 | x86_64 | insync repo
| insync-headless | package | 1.5.2.37346-fc25 | x86_64 | insync repo
| insync-nautilus | package | 1.3.12.36116-fc17 | noarch | insync repo
| insync-nautilus | package | 1.3.8.36087-fc17 | noarch | insync repo
| insync-nautilus-opensuse | package | 1.3.12.36116-fc17 | noarch | insync repo
| insync-nautilus-opensuse | package | 1.3.8.36087-fc17 | noarch | insync repo
| insync-nemo | package | 1.3.12.36116-fc17 | noarch | insync repo
| insync-nemo | package | 1.3.10.36104-fc17 | noarch | insync repo
But if I try to update, insync is ignored:
~> LANG=C sudo zypper dup --from insync Loading repository data... Reading installed packages... Computing distribution upgrade... The following 2 items are locked and will not be changed by any action: Available: teamviewer Installed: teamviewer-suse Nothing to do.
Thanks for the workaround. Is there an ETA for a proper fix to the upstream repo, and explicit support for Fedora 30?
Thanks.
Yeah, I’m starting to wonder if the package and repo will ever be updated for F30. It doesn’t look like such a monumental task now that a fix is out.
i moved to rclone an loving it… really a shame… love @insync team wish you all the best!
M
Workaround work, when will the F30 repo come online?
What I can do is recommend the Fed 30 build of Insync 3, now available via: Insync version: 3.0.11 beta - sync OneDrive!
Please let me know if this works or if you run into anything.
Fed 30 still not working right. Nautilus still not working and it want to sync my whole drive again. file matching is not working correctly!
Are you still running version 1.5.7 on your Fedora 30 machine, or have you migrated to Insync 3.x?
I have migrated to insync 3 but in my opinion version 3 is even worse. There are many bugs, some parts are still not complete (with an anoucement they are working on it) and strange behaviour… for example different users on the same Fedora 30 machine have different errors…
Hi Tomas,
So sorry for the trouble and I appreciate your patience with us. 
Our engineers are working to make sure that these issues are resolved as soon as possible.
Could you shoot me an email at support@insynchq.com regarding the bugs you encountered, including your OS and Insync versions? Please include the link to this post as well for reference. Thank you!