Docker calibre-web Problem enabling gmail account with OAUTH2 verification

I’m a happy user of linuxserver/calibre-web. I’ve just downloaded and started the latest version (0.6.12) which brings the opportunity to enable gmail account with OAUTH2 verification instead of standard SMTP email configuration, but when I try to enable it the service freezes.
I’ve followed the instructions of calibre-web project Setup Mailserver · janeczku/calibre-web Wiki · GitHub, created the gmail.json file and bind it into /app/calibre-web/gmail.json. Then I start the docker-compose, access through the UI /admin/mailsettings and choose “Gmail Account with OAuth2 Verification”, but when I click on the button “Setup Account as E-mail Server”, the spinner is running forever and nothing works anymore.

  • No messages are shown in docker-compose.logs or calibre-web.log.
  • After a loooong time I’ve got a generic error from apache which is running as proxy balancer (Proxy error…proxy server could not handle the request… Reason: error readin from remote server)
  • Even going inside the container and making a curl localhost:8083 request I have the same result. (It runs fine if I do it before trying to enable gmail conf)

The only solution to bring back to live is stop container and run it again with docker-compose.

Any advice here? somewhere when I can look for additional logs? Someone has configured successfully that service?

BTW this is my docker-compose.yml (very generic I would say):

---
version: "2"
services:
  calibre-web:
    image: ghcr.io/linuxserver/calibre-web 
    container_name: calibre-web
    environment:
      - PUID=1001
      - PGID=1001
      - TZ=Europe/Madrid
      - DOCKER_MODS=linuxserver/calibre-web:calibre
    volumes:
      - /srv/calibre-web/config:/config
      - /srv/calibre-web/books:/books
      - /srv/calibre-web/config/gmail.json:/app/calibre-web/gmail.json
    ports:
      -  127.0.0.1:8083:8083
    restart: unless-stopped

I just tested and also had isssues. Here is the feedback
hastebin - onepeponep

this was during the oauth link portion to an existing account, i didnt make it to a login attempt.

this failure was after following the changes mentioned in
Google Oauth error · Issue #1998 · janeczku/calibre-web (github.com)

as a note, in case you didnt know, you cant use oauth to login until you login normally and link your oauth account (this is per user, an admin can’t do it)

--------- it looks like a change is that calibre-web must be launched with the environment variable OAUTHLIB_RELAX_TOKEN_SCOPE which it looks like we dont mention in our readme yet.

to work around this issue, modify your compose and under environment, add

- OAUTHLIB_RELAX_TOKEN_SCOPE=1
then it will work. I just tested myself and was able to link the account, logout, login with google.

i’ve submitted
Cweb google oauth readme updates by drizuid · Pull Request #151 · linuxserver/docker-calibre-web (github.com)
to update the documentation to make this simpler for users.

Would be a good idea to add this into the readme as well!

Odd issue considering I use gmail with oauth2 with 0 problem and simply followed the documentation from the application site. I’ve been using it since I made the PR for oauth2. I think the little step by step towards the end of that thread is what you want us to add, but I think it would belong in the upstream documentation, not ours. We support the container, not the application.

I think you’re right in that does belong in upstream documentation, but the process defined in that link (Orgjvr’s post) is very much a container specific solution, including where to mount the gmail.json file, as well as how to access the link to allow calibre-web to send emails.

I found it essential for me (very much a newbie) to get it working, and I imagine having a reference to that process somewhere obvious would be useful for others as well. Maybe it’s enough that that link in here though, as this was the first post I came across when figuring out how to solve calibre-web’s unresponsiveness :slight_smile:

If it needs to open a random port and listen for a connection from the Internet (not sure about the second part but it is mentioned in that issue) it is most certainly not just a container issue.

Any local firewall running on the system would block that, requiring a specific allow and if it indeed needs to accept a connection from the Internet, the port would need to be forwarded on the router as well.

In any case, temporarily running the container with host networking would at least make that random port open and listening on the host.

In any case, this should definitely be documented in detail by the upstream project.