Thanks @Mecha_Weasel. Let me forward this info to our engineers and I’ll let you know if we need further details!
Again, we can’t thank you enough for your continued cooperation with the issue even if it has already been frustrating for you.
Replicating the same scenario that you have on our end, we’ve finally identified that the issue occurs when multiple Insync instances which use the same account and logged in via an auth code either through alternative login (in the GUI client) or web login (https://connect.insynchq.com/auth?cloud=gd) – again, huge thanks to you.
In line with this, we have this updated workaround. Specifically, the URL in step 3 has been updated with the proper parameters. A more permanent fix to both the client and the URL will be released soon.
- Remove the affected account from Insync via insync-headless account remove
- Remove Insync permissions for the affected account from https://myaccount.google.com/u/0/permissions
- Browse to the following URL and select the account to be used: https://accounts.google.com/o/oauth2/auth/oauthchooseaccount?response_type=code&client_id=468017360789-e4camv9a5n4e90tk4vrpk49qonmcm95s.apps.googleusercontent.com&redirect_uri=https%3A%2F%2Fconnect.insynchq.com%2Fauth-login&scope=openid%20email%20profile%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive.appdata&access_type=offline&prompt=consent&service=lso&o2v=1&flowName=GeneralOAuthFlow
- Add the account via
insync-headless account add -a [auth code] -c gd
using theauth code
given in step 3
Steps 3-4 should be done for each Insync instance.
This last workaround didn’t work for me.
When I start insync-headless
the application throws the following errors to console:
$ insync-headles start
[Errno 13] Permission denied: '.'INFO 2023-05-09 21:54:42,557 [mainlogs:_log_run:139] Core(app_version=3.2.6.10745, platform=Linux-x86_64-fedora/38) initialized
$ WARNING 2023-05-09 21:54:42,757 [base_events:_run_once:1767] Executing <Task finished coro=<SettingsMain._load_settings() done, defined at ideskcore/mainsettings.py:186> result=None created at ideskcore/mainsettings.py:160> took 0.188 seconds
INFO 2023-05-09 21:54:42,782 [app:start_core:49] core started
INFO 2023-05-09 21:54:42,783 [unix_socket_server:start:106] unix socket server thread start
INFO 2023-05-09 21:54:43,417 [httpclient:request:192] Curl error CurlError(65, "necessary data rewind wasn't possible") while requesting to 'www.insynchq.com'.
INFO 2023-05-09 21:54:43,418 [httpclient:request:195] Retrying later...
$
Last two lines appear in the terminal every minute.
When I add the account then it throws the following error (I remove the token for security purposes):
$ insync-headless account add -a X/XXXXXXXXXXXXXXXXX -c gd -p '/home/user/Documents/Google Drive' -e MS_OFFICE
ERROR 2023-05-09 21:55:41,600 [workbase:__run:257] While running AlternativeLogin(cloud='gd', auth_code='X/XXXXXXXXXXXXXXXXX')
Traceback (most recent call last):
File "idesksync/workbase.py", line 246, in __run
File "ideskcore/loginwork.py", line 127, in _do
File "idesksync/oauth2client.py", line 103, in get_api_key
File "idesknet/httpclient.py", line 187, in request
idesknet.httpclient.HTTPResponseError: (<HTTPStatus.BAD_REQUEST: 400>, b'{\n "error": "redirect_uri_mismatch",\n "error_description": "Bad Request"\n}')
ERROR 2023-05-09 21:55:41,602 [workbase:_log_task_exception:449] While running AlternativeLogin(cloud='gd', auth_code='X/XXXXXXXXXXXXXXXXX')
Traceback (most recent call last):
File "idesksync/workbase.py", line 246, in __run
File "ideskcore/loginwork.py", line 127, in _do
File "idesksync/oauth2client.py", line 103, in get_api_key
File "idesknet/httpclient.py", line 187, in request
idesknet.httpclient.HTTPResponseError: (<HTTPStatus.BAD_REQUEST: 400>, b'{\n "error": "redirect_uri_mismatch",\n "error_description": "Bad Request"\n}')
Sorry, an error occurred: (<HTTPStatus.BAD_REQUEST: 400>, b'{\n "error": "redirect_uri_mismatch",\n "error_description": "Bad Request"\n}')
$
This is the output of version command:
$ insync-headless version
3.2.6.10745
$
As I said in my previous post, if I go to https://myaccount.google.com/u/0/permissions I don’t see insync as an allowed application.
M.
I am currently dealing with a presumably unrelated issue (subscription expiration). So, can’t troubleshoot this more right now - until that’s resolved. Sorry.
Hi @maicmarin
Can you try using the token from this url instead?
https://connect.insynchq.com/auth?cloud=gd
Hey @Kurt_Ko,
Same error
$ insync-headless account add -a XXXXXXXXXXXX -c gd -p '/home/user/Documents/Google Drive' -e MS_OFFICE
Sorry, an error occurred: (<HTTPStatus.BAD_REQUEST: 400>, b'{\n "error": "redirect_uri_mismatch",\n "error_description": "Bad Request"\n}')
After allowing Insyc to access my account the application name does not show up in the Third-party applications with account access page.
Hi @Mecha_Weasel! I sent an email reply regarding the expired subscription, let me know if you got it!
Hey @Kurt_Ko,
I am using fedora. There is no apt-get
in this distribution.
Thanks for the follow-up.
M.
Hi @maicmarin
Can you run these instead and send us the output?
dnf list installed | grep insync
cat /etc/os-release
Hey… here you are:
$ dnf list installed | grep insync
insync-headless.x86_64 3.2.7.10758-fc31 @@commandline
$ cat /etc/os-release
NAME="Fedora Linux"
VERSION="38 (Server Edition)"
ID=fedora
VERSION_ID=38
VERSION_CODENAME=""
PLATFORM_ID="platform:f38"
PRETTY_NAME="Fedora Linux 38 (Server Edition)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:38"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f38/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=38
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=38
SUPPORT_END=2024-05-14
VARIANT="Server Edition"
VARIANT_ID=server
Yes, got it. That worked (in terms of getting my subscription activated again). So, syncing to DropBox is working again for me. Catching-up on the thread here regarding the Google Drive issues.
Hi @maicmarin
Can you try retrieving and auth code from https://connect.insynchq.com/auth?cloud=gd
and adding it to insync-headless
?
Note that the URL above starts with https://connect.insynchq...
this is different from https://www.insynchq...
Hi @Kurt_Ko,
Unfortunately using provided link didn’t work. I got this same error.
Any other think you want me to test?
Output of cat /etc/os-release; for my setup:
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
However, I am probably going to do an in-place upgrade from Debian 10/“Buster” to Debian 11/“Bullseye” next week.
PS: Output of insync-headless version; is …
3.2.7.10758
To avoid any complications with being signed-into multiple Google accounts in the same browser, I am doing this now to see if it makes any difference:
- Opening a new “Incognito” window in Chrome.
- Signing-into G-Mail, in that “Incognito” window.
- Opening https://connect.insynchq.com/auth?cloud=gd, in that “Incognito” window.
- Completing the setup of Insync-Headless using the auth code generated, in that “Incognito” window.
So far, everything seems to be working (at least account added successfully, and seems to be starting to sync / “scanning”). I will monitor to see if it stays that way, or (as before) later starts complaining about an “expired authentication token” after a while.
PS: Did that for all three (3) instances of Insync-Headless, each using a different authentication code generated in that “Incognito” window under Chrome.
UPDATE: 4 Hours later and …
- All three (3) instances eventually reached “SYNCED” status.
- The setup survived a REBOOT of the operating system.
- No indications of “authentication token has expired” so far.
I will continue to monitor over the weekend, and report back early next week to be sure.
Another update:
- A couple of days later, I can report that everything seems to be working as expected!
- No “authentication token expired” errors to report.
- Working on all three (3) instances as expected.
- Survived an operating system reboot.
I have successfully re-synced everything I had working before at this point. And seems to be keeping in sync again now.
Thanks!
That’s superb, @Mecha_Weasel! I appreciate the updates. Feel free to comment on this thread if anything comes up. Fingers crossed!
@maicmarin Pinged Kurt regarding this already - thank you for giving it a try and apologies for the continued troubles!