Internal Server Error 500 when trying to sign in with OIDC (Authelia)

Hi all,

I’m running my Gitea 1.21.4 instance in Docker and I’ve set up Authelia as an OIDC provider. Up until a couple of weeks ago, all was fine. Now, however, I’m unable to use Authelia:

2024/01/29 15:19:03 [E] SignIn: no provider for authelia exists
2024/01/29 15:19:03 ...eb/routing/logger.go:102:func1() [I] router: completed GET /user/oauth2/authelia for, 500 Internal Server Error in 30003.9ms @ auth/oauth.go:847(auth.SignInOAuth)
2024/01/29 15:19:03 .../providers_openid.go:44:CreateGothProvider() [W] Failed to create OpenID Connect Provider with name 'authelia' with url '': Get "": dial tcp XXX.XXX.XXX.XXX:443: i/o timeout
2024/01/29 15:19:03 ...ource/oauth2/init.go:73:initOAuth2Sources() [E] Unable to register source: authelia due to Error: Failed to initialize OpenID Connect Provider with name 'authelia' with url '': Get "": dial tcp XXX.XXX.XXX.XXX:443: i/o timeout.
2024/01/29 15:18:37 ...eb/routing/logger.go:68:func1() [W] router: slow      GET /user/oauth2/authelia for, elapsed 3821.8ms @ auth/oauth.go:847(auth.SignInOAuth)
2024/01/29 15:18:32 ...eb/routing/logger.go:102:func1() [I] router: completed GET /user/login?redirect_to=%2f for, 200 OK in 6.8ms @ auth/auth.go:141(auth.SignIn)
2024/01/29 15:18:30 ...eb/routing/logger.go:102:func1() [I] router: completed GET / for, 200 OK in 2.5ms @ web/home.go:32(web.Home) IS reachable, both from my machine AND from within Gitea’s container. Moreover, pinging it shows the correct public IP address. CURL, however, fails and I can’t understand why:

curl: (28) Failed to connect to 443 after 129531 ms: Couldn't connect to server

Traceroute returns just 2 hops, as it should.

Both Gitea and Authelia are within the same Docker network, on the same physical server.

Could someone help me figure out what’s causing this behaviour, please?


Is your firewall or docker configuration blocking the outbound HTTPS connection, even though ping is allowed? Until the cURL command works, it can’t work in Gitea either.

How do you determine that it’s reachable from the container when cURL is failing?

I made the wrong assumption that since ping was working, the IP was accessible. Clearly I was wrong.

As for the firewall, I have a Unifi Express gateway. There were some rules on it, but I disabled them while testing. I don’t know if there needs to be a specific setting that enables the TrueNAS server to communicate with itself.

More info from the latest hour: I inspected the Nginx Proxy Manager access and error logs while performing curl and strangely the attempts made from the TrueNAS server itself were not registered – other ones, performed from my computer, did appear in the log.

You would also have a firewall between containers and the host as set up by Docker.

From the container, can you curl to the host?

I think I solved the issue thusly:

Added a line in the server’s /etc/hosts file with and then in docker-compose:

      - /mnt/apps/data/gitea:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
      - /etc/hosts:/etc/hosts:ro
1 Like