Problem
Two problems show up as soon as the Docker Compose stack (deploy/docker/docker-compose.yml) is running.
No e-mail is ever delivered. The compose file does not configure mail, so the API uses the MailOptions:Smtp block from appsettings.json: host smtp.ethereal.email, port 587, empty credentials. Every confirmation, password-reset and welcome e-mail fails with authentication Required. The visible result is that a user registered by an operator cannot sign in, because the confirmation e-mail never arrives and someone has to confirm the address by hand (the operator's Confirm email action in the user detail page).
A local SMTP catcher such as Mailpit does not help either. SmtpMailService (src/BuildingBlocks/Mailing/Services/SmtpMailService.cs) always calls ConnectAsync(host, port, SecureSocketOptions.StartTls, ct), so a server that does not advertise STARTTLS is refused with The SMTP server does not support the STARTTLS extension before anything is sent. The same hardcoded mode also rules out providers that use implicit TLS on port 465.
Every API and migrator start logs a Kerberos error. Both images are built on aspnet:10.0-noble-chiseled, which does not include libgssapi_krb5.so.2. Npgsql defaults GSS Encryption Mode to Prefer, so the first connection logs Cannot load library libgssapi_krb5.so.2 and libgssapi_krb5.so.2: cannot open shared object file. The connection then succeeds, but the log reads as a failure.
Reproduction
cd deploy/docker && cp .env.example .env, fill in the required values, then docker compose up -d --build.
docker logs fsh-api: the libgssapi_krb5.so.2 lines appear on the first database connection.
- Sign in to the admin console and register a new user, or trigger forgot-password.
- The e-mail job fails (
authentication Required in the API log), and the new user cannot sign in.
Expected
- The compose stack delivers the e-mails it sends somewhere an operator can read them, with no external account needed, and documents how to switch to a real provider.
- The SMTP connection mode (
None, SslOnConnect, StartTls, ...) is configurable, and StartTls stays the default so existing deployments do not change.
- A normal start of the compose stack logs no
libgssapi_krb5 error.
Problem
Two problems show up as soon as the Docker Compose stack (
deploy/docker/docker-compose.yml) is running.No e-mail is ever delivered. The compose file does not configure mail, so the API uses the
MailOptions:Smtpblock fromappsettings.json: hostsmtp.ethereal.email, port 587, empty credentials. Every confirmation, password-reset and welcome e-mail fails withauthentication Required. The visible result is that a user registered by an operator cannot sign in, because the confirmation e-mail never arrives and someone has to confirm the address by hand (the operator's Confirm email action in the user detail page).A local SMTP catcher such as Mailpit does not help either.
SmtpMailService(src/BuildingBlocks/Mailing/Services/SmtpMailService.cs) always callsConnectAsync(host, port, SecureSocketOptions.StartTls, ct), so a server that does not advertise STARTTLS is refused withThe SMTP server does not support the STARTTLS extensionbefore anything is sent. The same hardcoded mode also rules out providers that use implicit TLS on port 465.Every API and migrator start logs a Kerberos error. Both images are built on
aspnet:10.0-noble-chiseled, which does not includelibgssapi_krb5.so.2. Npgsql defaultsGSS Encryption ModetoPrefer, so the first connection logsCannot load library libgssapi_krb5.so.2andlibgssapi_krb5.so.2: cannot open shared object file. The connection then succeeds, but the log reads as a failure.Reproduction
cd deploy/docker && cp .env.example .env, fill in the required values, thendocker compose up -d --build.docker logs fsh-api: thelibgssapi_krb5.so.2lines appear on the first database connection.authentication Requiredin the API log), and the new user cannot sign in.Expected
None,SslOnConnect,StartTls, ...) is configurable, andStartTlsstays the default so existing deployments do not change.libgssapi_krb5error.