This MessagingException: Exception reading response error is often related to network issues or SMTP timeout configuration. Here's how to address it:

Check and Adjust SMTP Timeout Settings

The default SMTP timeout in FusionAuth is 2 seconds, which may be too short if your SMTP provider experiences occasional network slowness. You can increase the timeout by:

Navigate to Tenants > [Your Tenant] > Edit > Email > Advanced In the Additional properties field, add or adjust these configuration values: mail.smtp.timeout=5000 mail.smtp.connectiontimeout=5000

This increases the timeout to 5 seconds. Adjust the value as needed based on your SMTP provider's typical response times. The Additional properties field can contain any Java mail property, and these values will override FusionAuth's defaults.

Email Retry Policy

FusionAuth does not have a built-in retry mechanism for failed email sends. FusionAuth connects directly to your configured SMTP server at the tenant level without using a local mail queue. If an email fails to send due to a connection issue or timeout, FusionAuth will not automatically retry it.

Additional Troubleshooting Steps

Enable SMTP Debug Logging: In your tenant's Email settings, enable the Debug enabled option. This will provide detailed SMTP transaction logs in the FusionAuth event log, which can help identify the root cause of intermittent failures.

Review Event Logs: Check System > Event Log for error events. FusionAuth always creates an event log entry of type "Error" when it cannot send an email.

Send Test Emails: Use the Send test email button in Tenants > [Your Tenant] > Email to verify your SMTP configuration under different conditions.

Implementing Your Own Retry Logic

To handle retries, you can set up a webhook-based solution:

Configure a webhook for the event-log.create event Monitor events delivered to your webhook endpoint When you detect a MessagingException event, trigger an API call to the appropriate endpoint (e.g., /api/user/forgot-password for password reset emails) Important: Implement retry limits in your script to avoid infinite loops with invalid email addresses

This approach gives you full control over retry logic, backoff strategies, and error handling for failed email deliveries.

Related Documentation Configure SMTP - SMTP Settings - Complete SMTP configuration guide Tenants - SMTP Settings Form Fields - Details on the Additional properties field and how to customize Java mail properties Troubleshooting Email - Comprehensive email troubleshooting guide Event Log Create Event - Documentation on the event-log.create webhook event for monitoring errors Start Forgot Password Workflow API - API endpoint for triggering password reset emails programmatically

Security notices are sent to users in your account.fusionauth.io portal who have been designated as a "Security Officer".

To ensure your team receives security advisories:

Log into account.fusionauth.io Assign the Security Officer role to anyone on your team who should receive security notifications There is no limit to the number of users you can assign this role to

This is documented in the FusionAuth security documentation.

By assigning this role to appropriate team members, you'll ensure that critical security advisories are delivered directly to your organization rather than relying on personal accounts.

The issue is related to the email template configuration for the mfa_deleter role. The mfa_deleter role has additional requirements beyond just assigning the permission - it needs a properly configured notification system to alert users when their MFA is removed by an administrator.

Key Requirements for the mfa_deleter Role

For the mfa_deleter role to work properly, the target user (the user whose MFA is being removed) must be notifiable through at least one verified primary identity:

Verified email: Requires the "Admin two-factor method removal" email template to be configured in your tenant's email settings Verified phone number: Requires the equivalent message template to be configured in your tenant's phone/messaging settings

The system enforces this as a security measure - when a non-admin user removes someone's MFA method using the mfa_deleter role, the affected user must be notified. If the target user doesn't have a verified email or phone number, OR if the corresponding template isn't configured, the operation will fail.

Resolution Steps Navigate to Tenants → [Your Tenant] → Email tab In the Template settings section, locate the "Admin two-factor method removal" field Assign a valid email template to this setting (you may need to create one first if it doesn't exist) Ensure the target users have verified email addresses Test MFA removal again with a user who has the mfa_deleter permission

Note: You only need to configure the notification method (email or phone) that matches the verified identity your target users have. You don't need both configured if all users have verified emails, for example.

Why Admins Can Remove MFA Without This

Users with the full admin role can remove MFA methods without these template requirements because they have elevated privileges. The mfa_deleter role is specifically designed for support teams and has additional safeguards to prevent abuse, including mandatory user notification.

Related Documentation The mfa_deleter Role - Official documentation on the role and its requirements User Support Guide - Remove MFA Method with mfa_deleter - Step-by-step guide for support teams Disable MFA on a User - General MFA management documentation Admin Two-Factor Authentication Method Removed Email Template - Template variables available for customization Tenant Configuration - Understanding tenant-level template settings

Hiya @hd_steve !

You can change the user's locale and the date format should change in the FusionAuth administrative user interface. More details here: https://fusionauth.io/community/forum/topic/718/how-do-i-change-the-localisation-timezone-for-the-fusionauth-ui?_=1614788141466

Let me know if that answers your question, please.

Thanks,
Dan

I think you are looking for kickstart: https://fusionauth.io/docs/v1/tech/installation-guide/kickstart

Here's how to run configure Kickstart to run when you are using docker: https://fusionauth.io/docs/v1/tech/installation-guide/docker/#kickstart

I'm not sure how you are starting your containers, but I imagine you could create and make a kickstart file available in other deployment environments also.

For exporting changes, it depends on how you make the changes. There's a community supported terraform module, but it doesn't cover all the apis (PRs welcome!).

You could also script all your changes using the API and apply those scripts to different environments. We mostly see folks writing migration scripts that call the APIs. These are very similar to database migration scripts except they make REST calls instead of SQL. The scripts are run during upgrades of their app. (If you are using an app like rails, you could even leverage the existing migration framework and a client library.)

Kickstart works well for dev envts and CI, but doesn't handle changes (it assumes there is no data in fusionauth and won't run if it sees any).

You can use the database.maximum-pool-size value in the fusionauth.properties file prior to 1.19.x ( it was just not documented) , but if you want to use the environment variable version is not available until 1.19.x.

When you re-index, we delete our named index and rebuild it.

You would probably be better off creating your own index.

There isn’t a single table in the db really. Configuration exists there, and in tenants, applications, etc.

Not with a FusionAuth policy, but you could enforce it just by checking the user during login, as twoFactorEnabled is an attribute of the user.

There's also this github issue which you may want to vote up: https://github.com/FusionAuth/fusionauth-issues/issues/763

@mangeshp16 The original question is over two years old. Since version 1.42, you can enforce MFA at the tenant level (or the application level if you have the enterprise plan). This means that any user who logs in is required to have MFA. If they do not, they are redirected to a page where they can set it up.

There are other ways to accomplish this. You could build your own MFA page which would call the APIs directly. When a user logs in, you can check to see if they have any twoFactor methods available and if they don't, you can send them to this page.

Doing so will allow FusionAuth to run even when utf8mb4 is not configured properly. We added that enforcement to ensure the limitation is understood before you turn off the enforcement.

The implication is that if you attempt to store a 4 byte unicode character the INSERT or UPDATE request will fail. The initial MySQL UTF-8 support only allowed for 3 byte characters, they then came out with utf8mb4 to support 4 byte characters.

For example, many emoji are 4 byte characters, so if you tried to store a piece of text with a smiley such as 😁 it will fail. The 😁 is a four byte character, U+1F601 or \xF0\x9F\x98\x81.

Unless you configure MySQL to use utf8mb4 any character points between U+10000 and U+10FFFF will fail to be stored.

Extracted from https://github.com/FusionAuth/fusionauth-issues/issues/234#issuecomment-632757441

That's configurable at the tenant level.

The default is 180 seconds, but it is customizable in the tenant settings: https://fusionauth.io/docs/v1/tech/guides/passwordless#one-time-code-customization

This is not currently available.

The plan is to build out SMS templates that can localized and customized but no timelines have been determined.