FreePBX Apply Config failed: isolate generation from reload

Freeze the failed change and define its scope

Record the Apply Config message, time, administrator, page just changed and whether calls are currently affected. Preserve the pending GUI values and the last known working configuration or backup. Do not keep pressing Apply Config: repeated attempts can mix a deterministic configuration error with later state changes and make the original failure harder to identify.

Check one existing internal, inbound and outbound workflow only if doing so is safe. A red Apply Config indicator does not prove that every previously loaded object stopped working, and a working old route does not prove the new configuration was generated or loaded.

Capture the supported reload result

From an authorized local or managed console, use the installed command help first. Sangoma documents that every fwconsole command accepts help and identifies fwconsole reload or its r alias as the operation that reloads FreePBX configuration and Asterisk. Run the supported reload once in the approved maintenance context and retain its complete output, exit status and matching log time.

Treat the first specific module, file, parser, database or Asterisk error as evidence, not as a reason to run every generic repair command. Do not publish credentials, numbers or customer identities from the output. A browser-side unknown error and a console-side generator exception are different evidence.

Separate generation failure from Asterisk reload failure

Establish whether FreePBX failed before writing configuration, wrote only part of the intended state, or reached Asterisk and received a load or reload error. Compare the failing component with the exact GUI object changed. Do not edit FreePBX-managed generated files as the primary repair; a later Apply Config can overwrite them and conceal the authoritative database or module problem.

Asterisk documents that CLI commands are supplied by loaded modules and may be absent when their component is not loaded. Use CLI help and read-only show commands that exist on the installed system. For a dialplan change, dialplan show <context> can prove what Asterisk loaded. For a PJSIP object, pjsip show endpoint <name> or the matching object command can prove loaded state. An object missing from Asterisk narrows the branch but does not by itself identify why generation or loading failed.

Repair the named owner, not every subsystem

Route the exact first failure to its owner: the FreePBX module that generated the object, the database or storage layer, the certificate or file referenced, or the Asterisk module that rejected it. Verify version-appropriate module health and available space before changing ownership, deleting cache, reinstalling packages or restarting services. Sangoma documents fwconsole chown as a broad ownership operation; do not use it blindly when the evidence does not identify permissions.

Likewise, fwconsole restart stops and starts managed processes and is not equivalent to a configuration reload. A restart can interrupt active calls and may temporarily hide rather than repair a generation error. Use it only when the specific repair and change window require a process restart.

Apply once and verify the intended object

After correcting the demonstrated cause, run the supported Apply Config or fwconsole reload path once and retain the successful output. Confirm that the intended dialplan context, endpoint, route, trunk or other object appears in Asterisk with the expected value. Asterisk's dialplan guidance explicitly pairs reload with dialplan show verification; use the equivalent read-only evidence for the affected subsystem.

Repeat the original workflow and a bounded regression set, including two-way audio and hangup only if call handling was touched. Record the change, before-and-after evidence, operator, rollback and remaining warnings. No FreePBX module, database, generated file, permission, Asterisk reload, endpoint, route, trunk or live-call behavior was tested for this guide.

After a restore, identify the missing owner before applying again

Use the missing settings or files diagnostic to prove whether archived data, a module restore handler, filesystem object or generator is absent. Repeated Apply Config attempts cannot restore source content that was never archived or handled.

Keep stale Misc Destination state in the apply-config evidence chain

The Misc Destination diagnostic compares saved, generated and loaded targets without editing generated FreePBX files as a durable repair.

Keep Apply Config separate from administrator authorization

If login succeeds but the expected page is hidden, use the Admin login diagnostic before treating the symptom as an Apply Config failure.