Anyone else having problem with keeping Jottacloud (or whitelabel) connections alive ?
As I explained in a locked topic, I use run ‘rclone about jotta-archive:’ (or actually a script that does that now) every 5 minutes (previously 15) to keep the connection alive and having the access token updated, but it recently stopped working (around DST time mess-up, in the end of March).
I usually updated to the latest (non-beta) version every now and then, but went back to 1.73.0 to investigate the problem further, but that made no difference, the config is not updated and I loose the connection after about an hour.
This might indicate something on the backend (at Jotta) has changed, if not going back some further versions solves this.. (and I can ask people at Jotta about it too, but as rclone is “unsupported” they will probably not prioritizing in fixing something that isn’t broken)
So just asking, not blaming, but it’s annoying getting ‘CRITICAL: Failed to create file system for "jotta-archive:": couldn't get customer info: Get "https://api.jottacloud.com/account/v1/customer": couldn't fetch token: invalid_grant: maybe token expired? - try refreshing with "rclone config reconnect jotta-archive:’ on the backup server and on the two Synology NASes I have set up the cron jobs on to keep the connection alive.
Self-reply (probably a too small user base for Jotta/Elgiganten customers)
I got (at least for now) the Debian machine to update the token before it expires (5 minute interval on the cronjob) using version 1.73.0. The two Synologys still lost the connection after that first hour, also running 1.73.0.
As I have a script that logs the result from ‘about’, I know it runs as expected (so no problem with cron on the Synologys). The next attempt is to run my script every minute, since 5 minutes was not good enough on these devices.
Could this be part of the problem ?
Is there any way to set the ‘device name’ even if the intent is to access the ‘archive’ (which requires no device and no mountpoint) ?
.. and I always forget to mention that I use different tokens for connections from different machines (Linux machine, DS1517 and DS918)
I have no idea what is going on here, and why you had to do this:
I use run ‘rclone about jotta-archive:’ (or actually a script that does that now) every 5 minutes (previously 15) to keep the connection alive and having the access token updated
Regarding this:
Is there any way to set the ‘device name’ even if the intent is to access the ‘archive’ (which requires no device and no mountpoint)?
Which of the Jottacloud backend's autentication types are you using?
Yes,that’s it, but I have included the relevant information in this thread (as that old one was about the initial fix to allow the whitelabel Jottacloud versions to work with the new authentication method).
Even with a one minute interval the config (and token) is not being updated (this is on 1.7.0, as the log shows):
root@DS1517:~# cat /volume1/jotta-status
Tue Apr 14 23:54:01 CEST 2026
-rw-rw-rw- 1 root root 2427 Apr 14 22:41 /root/.config/rclone/rclone.conf
2026/04/14 23:54:01 DEBUG : rclone: Version "v1.73.0" starting with parameters ["/bin/rclone" "-vv" "--config" "/root/.config/rclone/rclone.conf" "about" "jotta-archive:"]
2026/04/14 23:54:01 DEBUG : Creating backend with remote "jotta-archive:"
2026/04/14 23:54:01 DEBUG : Using config file from "/root/.config/rclone/rclone.conf"
2026/04/14 23:54:01 DEBUG : jotta-archive: Token expired
2026/04/14 23:54:01 DEBUG : jotta-archive: No updated token found in the config file
2026/04/14 23:54:01 DEBUG : jotta-archive: got fatal oauth error: oauth2: "invalid_grant" "Session doesn't have required client"
2026/04/14 23:54:01 CRITICAL: Failed to create file system for "jotta-archive:": couldn't get customer info: Get "https://api.jottacloud.com/account/v1/customer": couldn't fetch token: invalid_grant: maybe token expired? - try refreshing with "rclone config reconnect jotta-archive:"
My impression is that the error message you get is the typical case where the current refresh token has been invalidated following (one hour later) an attempt to perform token refresh using a previous refresh token. But you seem very certain that there is not an actual refresh token reuse scenario here...
Regarding the "My logged in devices". I only have access to the main Jottacloud service, not a whitelabel. I get "Jottacloud CLI" listed when using standard authentication (i.e. personal login token) and "Jottacloud for Desktop" when using what rclone currently calls traditional authentication (i.e. more traditional OAuth). I'm not able to use the legacy authentication. Are you using the traditional authentication as well? But you get "rclone" listed, and there is no difference in client id ("desktop") or scopes that are supplied during authentication, so the whitelabel service authentication does something different then...
As the log shows, the last time the config file was updated was at the time I manually updated the token I got from rclone (on another computer - just a config I set up for this particular client - never used on the computer I created it on and immediately deleted to prevent usage).
Elgiganten cloud (and probably Elkjöp and the other equivalents) customers have to use ‘traditional authentication’ because we cannot create personal tokens in the WebUI (so the steps in the configuration is '33’→’2’→’3’). ‘Legacy authentication’ is gone since September (when the actions were taken to support these whitelabel versions).
This time, I updated the token on another (real) Linux machine, and set a cron job to run my refresh-script every 5th minute. Also changed the logging to append to the file, so I can check the exact moment of losing the token in the log afterwards.
Maybe a ‘rclone about’ just isn’t good enough for keeping the session alive anymore ?
On the server that still keeps the connection alive, I use ‘serve s3’ to make it available to xcp-ng, and XO probe the backup remotes often to check their status (still, it broke with the latest version of rclone, but with 1.73.0 it’s kept alive, at least in combination with ‘about’ every 5th minute).
For three days now, I have been able to keep a rclone connection alive against the Jotta (Elgiganten variant) backend. Unfortunately not ‘fully headless’, since this is on my dev Linux machine with Ubuntu Desktop (that I usually never use, but this time used it to create the token).
The conclusion is that the authentication token contains information on the actual device it was created on, and (even if that is never used on that device once it has been created and deleted) this causes the “got fatal oauth error: oauth2: "invalid_grant" "Session doesn't have required client"" when it’s time to update the token on another computer (or device, in this case a Synology NAS, but I get the same problem with a true headless Linux machine).'
I’ve also tried another method to get the token using a SSH tunnel (‘ssh -L 53682:127.0.0.1:53682 user@headless-host') from a ‘headed’ machine to access the server on ‘localhost’ of the headless machine, but this cause the same issue - the authentication token fails its first renewal. I have not tried the ‘socat’ method also described in the below post (should also work with ‘nc’), but as that still requires the token to be created from the headed machine, that should also fail on renewal.
