New Insync version: 1.3.2

None :wink: I’m using i3 window manager. which gsetting are you querying to determine scaling? i can set this in my startup scripts…

@Sascha_Appel org.gnome.desktop.interface scaling-factor. It’s an integer value, so 2 would scale 2x, etc.

Have a problem with the portable release on centos64 . I get this error message:

Run insync-portable help for help with a specific command
Traceback (most recent call last):
File “”, line 6, in
File “”, line 128, in
File “”, line 106, in
IndexError: list index out of range

@marcus_specht That error is just minor and shouldn’t prevent Insync from running normally. It will be fixed in the next release. Thanks for the report.

As much as I love the idea of file matching, the latest update has fubared my Insync installation. "Syncing for folder is paused because it went missing.

Ubuntu MATE 15.04 x64
Synced folders symlinked to an external HDD (for portability reasons)

The above setup was working great until a subsequent update prevented me from syncing local files to the cloud. A force sync was necessary every time local content had changed. I have been emailing support forth and back but never got a final response for a fix.

With the latest update nothing gets synced anymore. Not happy, as I have over 600 GB of data.

Hi @lpugoy, I have exactly the same problem of @marcus_specht .
If I run ./insync-portable start, “nothing happens”
When I run ./insync-portable get_status, then I receive the message: Insync doesn’t seem to be running. Start it first.
When I run ./insync-portable start --no-daemon, then I receive the errror bellow:

Traceback (most recent call last):
File “”, line 6, in
File “”, line 128, in
File “”, line 131, in
File “”, line 25, in main
File “ideskmain/”, line 3, in
File “ideskmain/”, line 1, in
File “ideskmain/”, line 5, in
File “idesksyncer/”, line 10, in
File “idesknet/”, line 4, in
File “idesknet/”, line 13, in
File “ideskmain/”, line 9, in
ImportError: No module named psutil

My system has the python-psutil package installed.
I’m running the insync-armhf_1.3.2.36049_i386 version.

Have you any idea?

Any idea when a new version will come out that will speed up the initial sync? I’m on a 100mbps connection and still have ~43.000 files to sync out of 60,000; it’s been running for about 5 hours now… I could use gsutils to do the initial download, but I don’t know how insync would handle that or if it would freak out. gsutils is substantially faster.

I’m using insync-headless- on a CentOS 7 box

Edit some supporting information:
insync-gdrive-linbit/Clients# insync-headless get_sync_progress | grep files; date
42903 files queued
Thu Oct 15 15:13:18 PDT 2015

insync-gdrive-linbit/Clients# insync-headless get_sync_progress | grep files; date
41119 files queued
Thu Oct 15 15:42:31 PDT 2015

insync-gdrive-linbit/Clients# insync-headless get_sync_progress | grep files; date
39962 files queued
Thu Oct 15 16:01:16 PDT 2015
insync-gdrive-linbit/Clients# du -sh
14G .

These files are all relatively small under a meg each.

@Wagner_Lima: Apologies for that. New builds have been uploaded to resolve the psutil issue. You can get them at

@TimK The issue you had before was resolved in this release as well. For your current issue please send your logs to for investigation: How to find the log files

It works very well! Thanks.

Hi, i have Centos on my PC and on installing Insync i have the below issue:
{“message”: “SSL certificate validation failed! (host: %s, error: %r)”, “params”: [“”, “SSLError(1, ‘_ssl.c:504: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed’)”]}

Please, help.

PS: there is no proxy.

When I run Insync with –no-daemon I get a bit of log to console that seems relevant.

INFO     2015-10-16 18:22:04,676 [__init__:info:1614] Syncing GDUser(id=u'somenumber', email=u'', name=u'myname').
INFO     2015-10-16 18:22:04,862 [__init__:info:1614] There are no existing trees.

This then pops up when I select Resume syncing from the Actions Required menu in the GUI.

INFO     2015-10-16 18:24:14,073 [__init__:info:1614] unwatching /home/tim/Google Drive/***
WARNING  2015-10-16 18:24:14,074 [__init__:warning:1604] removing a watch ID by a path that's not in self.paths, skipping: /home/tim/Google Drive/***
INFO     2015-10-16 18:24:20,129 [__init__:info:1614] Main tree type for u'***' changed

Needless to say, the folder it claims is not there is indeed very much alive.

I can’t get Insync to add my account, not through either method of logging in.
I get the following output in terminal (account details removed):

$ insync start --no-daemon
INFO     2015-10-17 06:44:38,077 [__init__:info:1614] insync version:
INFO     2015-10-17 06:44:38,079 [__init__:info:1614] client created <ideskmain.client.Client object at 0x7f8af9b46cd0>
INFO     2015-10-17 06:44:38,079 [__init__:info:1614] unix socket server thread start
INFO     2015-10-17 06:44:38,080 [__init__:info:1614] starting client
INFO     2015-10-17 06:44:38,085 [__init__:info:1614] LinuxFSWatcher._start
INFO     2015-10-17 06:44:38,086 [__init__:info:1614] Inotify loop enter
INFO     2015-10-17 06:44:47,124 [__init__:info:1614] Error during reading of response!
INFO     2015-10-17 06:44:58,785 [__init__:info:1614] Setting up GDUser(id=u'<numbers here>', email=u'<my email>', name=u'<my name>').
INFO     2015-10-17 06:45:00,012 [__init__:info:1614] Initializing list of files.
ERROR    2015-10-17 06:45:08,637 [__init__:error:1588] While adding a new account
Traceback (most recent call last):
  File "ideskmain/clienttasks/", line 40, in _run
  File "ideskmain/clienttasks/", line 101, in __setup
  File "idesksyncer/", line 176, in start_new_account
  File "idesksyncer/", line 568, in __start_new_account
  File "idesksyncer/", line 159, in setup
INFO     2015-10-17 06:45:39,124 [__init__:info:1614] No updater available.

I’m running a fresh install of Kubuntu 15.04.

Will it work on a dual boot Windows10/Linux Fedora22 system? May I use the same Insync local folders to syncronize with each OS? I’m feared about messing everything. It happened once and took me one day long to fix.

@Abhishek_Sharma: Are you still experiencing this issue? Does it always happen or only sometimes?

@TimK: Have you sent your logs to

@cguimabr: 1.3.2 still doesn’t support using the same folder on different OS, apologies.

@lpugoy I binned the old setup and I’m very pleased to confirm that file matching works perfectly. Over 600 GB and 200k files matched in a little over a day, instead of downloading over a week.

Will the force share (=spamming) feature be dropped?

Does 1.3.2 support Fedora 23 64bit?

@Totalitout: Yes, Fedora 23 is also supported.