SOLVED: FATAL ERROR when updating an extension

FreePBX running in production environment. System runs flawlessly in moderate volume call center.

Just noticed an issue but not certain how long the problem has been there: the interface is fine in all respects except that if you try to update an already existing extension [e.g. just open the extension and hit submit], you get a blank white screen with “FATAL ERROR” in headline font … nothing else whatsoever. Interestingly the same interface will happily allow you to delete an extension and add and extension [the easy workaround] and they all update the DB just fine and create the appropriate code in the extensions_additional.conf file when the orange bar is touched.

Everything else works fine and since editing an extension is a fairly uncommon task, no one really knows when this started.

Anyone seen and fixed this?

I once had a FATAL ERROR DB Error: connect failed

It was caused by messing with my passwords early up.

After triple-checking that all passwords matched, I finally used WebMin - MYSQL Database Server to open up the permissions.

Problem: Sometimes defining an extension generates FATAL ERROR. Error: Trying to
write null voicemail file! I refuse to continue!
Solution: Define the extension with voicemail enabled, and apply the config. Then go back
and disable it. Alternatively copy and from /usr/src/freepbx-
2.3.1/amp_conf/astetc to /etc/asterisk


Sadly neither of these leads seem to apply: we clearly have good DB connectivity since freePBX is adding and deleting just fine, as well as managing all the other functions [queues, trunks, routes, followme etc]. The only thing is the update to an existing extension. This problem occurs with ALL extensions, not just one extension, although I recognize that one bad piece of data could possibly do this. The message also does not say this is a DB Error [although somehow the DB is likely involved given where the error occurs]… but all it says is “FATAL ERROR”

We can create extensions fine. Here is where I realized this is a more annoying issue: there are certain SIP settings on an extension [e.g. NAT] that are only available after the extension is created, so we do have to edit more often than I first thought and the delete/add workaround that we had is only of use if we can live with the default SIP settings.

I have googled this ad nauseum and still no luck. I guess code diving is next…

This one suggests a bug of some sort.

I deleted an extension. It went away fine. Hit orange bar. All good.

I then added an extension with the same number. I selected “Voicemail Disabled” and added it just fine. Now I pulled the extension back up as if i was going to edit it and, lo and behold. it showed VM enabled complete with the mailbox’s email address etc. In other words, when the “DELETE” took place, not ALL of the data associated with that extension were deleted.

Code diving now but I am going to hypothesize that on an edit, it is trying to insert certain data related to voicemail into some table that is preventing it with some type of constraint…

permissions on voicemail.conf messed up… apparently by data stamp this occurred 4 days ago…the mystery which is of lesser importance is why.

Those damn permissions. I agree that things are left behind that shouldn’t be. Mine still tells me that I have a weak secret on one extension. It was weak, but is now 12 characters, a combination of upper and lower letters and numbers of complete gibberish.

I had the same problem. I am fairly certain I caused it myself. Somewhere along the way I had reloaded asterisk with “service asterisk restart” as root. This isn’t quite the same as letting things start up on their own during the normal boot process. Once I rebooted and let all of the services start the “right way”, all was well.

Just thought I would throw this out there in case anyone else is having the same issue.