#HEADLESS #LINUX "Your authentication token has expired"

Bugs and issues Linux
#1

My environment:

  • OS: Debian 10 “Buster” (64-bit) - planning to upgrade soon to Debian 11 “Bullseye” btw.
  • Product: Insync Headless for Linux (3.2.7.10758)

Utilization:

  • One Linux server.
  • Multiple copies of Insync Headless running.
  • Each running under different Linux user.
  • All synchronizing different sets of sub-folders from the same Google One Drive account.
  • Obviously, different authentication tokens generated used for each Headless instance (each Linux user). - since (presumably) those authentication tokens can only be used once.
  • This all worked fine previously.

Got everything setup, was running fine for a while, then start getting messages like this:

I check the status:

insync-headless status;
Accounts:
xxxxx@gmail.com (Google Drive)

Sync status: ERROR
(See insync-headless error list or insync-headless conflict list for details.)

Syncing files:
/home/xxxxx/googledrive/xxxxx - scanning

Then I check the errors:

insync-headless error list;
1 - Your authentication token has expired. Please try logging in again.
Choose an error to resolve (1 - 1, 0 to quit): 1
1 - Login
Choose an option (1 - 1, 0 to cancel): 1

Then I check the status again:

insync-headless status;
Accounts:
xxxxx@gmail.com (Google Drive)

Sync status: SYNCING

Syncing files:
/home/game-servers/googledrive/xxxxx - scanning

#2

Hi! This is a known issue at the top of our engineers’ priority list. Thank you for reporting and my apologies for the trouble.

Could you send your log files to support@insynchq.com with the link to this post? Please include the ff:

  • logs.db
  • out.txt
  • data folder
  • live folder

These should be in ~/.config/Insync-headless.

#3

The zip-files I made containing that information for each account are too large to email (100-MB to 300-MB each). So sending my DropBox link in the email.

PS: None of the 3 instances are currently throwing the “expiration” error, but 2 of the 3 are still in a “scanning” state.

#4

Also 2 of the 3 instances to represent a large amount of data.

  • 3935 files, spread over 78 folders, representing about 27.5-GB of data.
  • 18314 files, spread over 916 folders, representing about 18-GB of data.
  • 49 files, spread over 7 folders, representing about 795-MB of data.
#5

I received a message, asking to do this:

Hey there! Could you try to do the following, please?

Remove the affected account
Under Google Account > Apps with access to your account, click on Insync and select remove access.
Do the headless login flow afterwards–
When you get redirected after step 1 in the headless add account flow, you need to copy and modify the URL. Here are the steps in detail:

  1. After browsing to http://connect.insynchq.com/auth?cloud=gd, you get redirected to this page. Copy the URL in the address bar:

  2. Modify the URL by adding the following at the end:

&access_type=offline
3. Browse to the modified URL and login using the selected account. Proceed with the normal headless add account flow.

While I appreciate the fast response. deleting the account and basically starting over (including re-syncing all my data and dependencies) on a production server, isn’t really something I want to “try” as a troubleshooting step.

If it is the known/documented (one-time) permanent fix, then so be-it. But “try” - Not so much so.

1 Like
#6

I understand the apprehensions to give the workaround a try, @Mecha_Weasel. You may hold off doing so until I get more information on the issue (both from users and our engineers) as we have received mixed results from said workaround.

As for the logs, if it’s possible for you to upload them in the cloud (i.e., WeTransfer) and send me a shared link to download, that would be much appreciated!

#7

Update: Please disregard the last point re: logs! I see you’ve sent it and my colleague is attending to said ticket.

Thank you!

#8

I might get a chance today/tomorrow to take the system down for some unrelated maintenance.
If so, I will try the work-around, since 2 of the 3 instances are not actually synchronizing anyway.

Is there any new version of insync-headless I should think about trying? or still headless_3.2.7.10758?

#9

Trying the work-around (http://connect.insynchq.com/auth?cloud=gd&access_type=offline and so-forth) right now. Two (2) of three (3) instances (the large ones) are showing “scanning” status afterwards. I will monitor them, and see if they eventually complete, or throw the token expiration error again.

#10

Thank you for trying @Mecha_Weasel. There is currently no new release of headless - it’s still 3.2.7 for your reference. Thank you again!

#11

Currently, the two large ones have finished synchronizing, and are showing “SYNCED”. I will let everything run overnight and check tomorrow.

After that, I will try a reboot - to see if the work-around survives a reboot (which others have reported is possibly still an issue).

#12

PS: I noticed that the insync-headless account help page still shows the older authentication URL to use (without cloud type specified), as opposed to the help page output for insync-headless account add.

Output of insync-headless account …

Usage: insync-headless account [OPTIONS] COMMAND [ARGS]…

List, add, or remove accounts.

Options:
–help Show this message and exit.

Commands:
add Add an account via auth code from https://connect.insynchq.com/auth.
list List existing accounts.
remove Remove an account.

Output of insync-headless account add …

Usage: insync-headless account add [OPTIONS]

Options:
-a, --auth-code TEXT Auth code received from signing in at https:
//connect.insynchq.com/auth?cloud=
-c, --cloud [gd|od|dx] Cloud provider to add the account for:
Google Drive (gd) / OneDrive (od) / Dropbox
(dx).
-p, --path TEXT Path to sync your files to.
-e, --export-option [LINK|MS_OFFICE|OPEN_DOCUMENT]
Export option for Google-format items.
–help Show this message and exit.

1 Like
#13

Oddly enough, two (2) of the three (3) instances are fully “SYNCED”.
And those are the very large ones (both in terms of number of files and total size to synchronize).
The one (1) instance that still shows “SYNCING” hour+later is the tiny one.

As it so happens, it was the third one I setup.

I am wondering if Google has placed some limitation how many instances of the same application (“Insync” as far as Google is concerned) can be activated? Maybe limiting it to two or something?

#14

Update: On that third instance (the one with the least files and data, but was 3rd one activated), It just threw the error again - requiring selecting the option to login again:

insync-headless error list;
1 - Your authentication token has expired. Please try logging in again.
Choose an error to resolve (1 - 1, 0 to quit): 1
1 - Login
Choose an option (1 - 1, 0 to cancel): 1

#15

Update-2: At this point all three (3) instances have thrown the same error requiring re-login. So, the work-around definitely does not “work” unfortunately.

#16

I can confirm the same. Work around doesn’t work even in a fresh install.

In my case, insync runs fine for about 1 hour and then stops working. To make it work again it is necessary to ask for a new token again.

1 Like
#17

My environments (where it definitely is still not working):

Server:

  • Debian 10
  • Insync Server/“headless” v3.2.7.10758

Client:

  • Windows 11 Pro (with latest updates).
  • Google Chrome (latest version)
  • Google account with “Google One” storage upgrade.
#18

Thank you all for the information you shared and my apologies for the persistent issues.

@Mecha_Weasel @maicmarin Please do send a fresh set of log files (logs.db and out.txt) for each machine showing the issue. Kindly forward these files to support@insynchq.com with the link to this post. Thank you very much!

#19

New set of logs just sent.

1 Like
#20

Received, @Mecha_Weasel. Thanks for sending it my way!