gmailr token name does not match hash

I am failing in trying to use gmailr on a headless server, though I have another server where it is working. I have looked through the documentation, but I have not found anything similar to my problem.
Several months ago I set up an Oauth Client account at Google, downloaded the json file and generated a token. I use the json and the token on my personal laptop and on a remote headless server every day. The laptop runs Linux Mint 18.3 and the server runs Ubuntu 16.04. I have now copied, via scp, the same json file and token to a new machine running Ubuntu 22.04. When I try to send an email, I get the message
! Cache contains a token with a name that does not match its hash:
The token is then renamed and the process fails, as shown below where the gargle verbosity has been set to "debug".
I would be very grateful for any guidance, as I am a novice at authentication set up.
See Edit below

> library(gmailr)

Attaching package: ‘gmailr’

The following object is masked from ‘package:utils’:


The following objects are masked from ‘package:base’:

    body, date, labels, message

> options(gargle_verbosity = "debug")
> options(gargle_oauth_email = "")
> gm_auth_configure(path = "mail/MyApp2.json")
> gm_auth(path = "mail/MyApp2.json", cache = "mail")
trying `token_fetch()`
trying `credentials_service_account()`
JSON does not appear to represent a service account
Did you provide the JSON for an OAuth client instead of for a service account?
trying `credentials_external_account()`
aws.ec2metadata not installed; cant detect whether running on EC2 instance
trying `credentials_app_default()`
trying `credentials_gce()`
trying `credentials_byo_oauth()`
Error caught by `token_fetch()`:
inherits(token, "Token2.0") is not TRUE
trying `credentials_user_oauth2()`
Gargle2.0 initialize
adding "" scope
! Cache contains a token with a name that does not match its hash:
• "" (name)
• (hash)
  Will attempt to repair by renaming
loading token from the cache
no matching token in the cache
initiating new token
Waiting for authentication in browser...
Press Esc/Ctrl + C to abort
/usr/bin/xdg-open: line 882: www-browser: command not found
/usr/bin/xdg-open: line 882: links2: command not found
/usr/bin/xdg-open: line 882: elinks: command not found
/usr/bin/xdg-open: line 882: links: command not found
/usr/bin/xdg-open: line 882: lynx: command not found
/usr/bin/xdg-open: line 882: w3m: command not found
xdg-open: no method available for opening ''

I can focus this question better with the following example. Why does the value of the token hash change when it is copied to server3? I forgot to mention that the R versions are very different (there are obstacles to updating server2 and I kept the laptop in the same state) but I'm only copying the token, I think.

#On my laptop (Linux Mint 18.3, R 3.5.1)
> TOKEN <- readRDS("mail/")
> TOKEN$hash()
[1] ""

#scp the files to the two servers

fjcc$ scp mail/  username@server3:~/R/                                                       100% 7256     7.1KB/s   00:00    
fjcc$ scp mail/  username@server2:~/R/                                                       100% 7256     7.1KB/s   00:00

#Check the hash on server2 (Ubuntu 16.04, R 3.5.1)
> TOKEN2 <- readRDS("")
> TOKEN2$hash()
[1] ""

#Check the hash on server3 (Ubuntu 22.04, R 4.2.1)
> TOKEN3 <- readRDS("")
> TOKEN3$hash()
[1] ""

First thing I'd try changing is the version= and/or the compression= arguments for saveRDS() and readRDS().

Thanks! That's an interesting idea but it did not work when I tried it. I even tried using save()/load() instead of readRDS and I still see the change in the hash value on server3. It is late for me, so I'll try it again tomorrow to make sure I did not make a mistake.

Maybe its an encoding issue, see:

Thanks for finding that. I'll see if I can make some progress along those lines and I'll report back if I find any solution.

Looks like the same encoding problem is reported here:

I don't have a Linux machine to test this myself.

The cause of the problem was a change to the version argument used in the base::serialize() function during the hash() calculation. Updating my local R version to match the R 4.2.1 on the remote system fixed the problem. I learned about this from Jenny Bryan on the github repository for gmailr.

1 Like

This topic was automatically closed 42 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.