Restore from FreePBX 12.0.76 server to a test server - CDR issues

Hi everyone, I’m trying to perform a Restore from a FreePBX 12.0.76 server to a test server. I have done many (many) restores over the years using previous versions of FPBX without any issue. Unfortunately I’m running into a password issue that has me completely baffled involving CDR and MySQL.

This is what I see and yes, reviewed many blogs about fixes but none work or don’t apply.

SQLSTATE[28000] [1045] Access denied for user ‘freepbxuser’@‘localhost’ (using password: YES)
Trace Back
/var/www/html/admin/libraries/BMO/Database.class.php:70 PDO->__construct()
[0]: mysql:host=localhost;port=3306;dbname=asteriskcdrdb
[1]: freepbxuser
[2]: 95be456eXXX

I can connect to MySQL with the password (909a59f73XXX) shown in freepbx.conf, cdr_mysql.conf and amportal.conf they are the same password in each. I can disable CDR Reports and error goes away – but I need the reporting.

It makes sense to me that I have an error because the restore is trying to load MySQL with the wrong freepbxuser password. Short of ripping the tgz apart and recompiling it with the right freepbxuser password, I’m not sure where to go next, so any help would be appreciated. Maybe I’m missing something very fundamental.

I’m happy to provide additional information required.

Thanks in advance!



Try this: Phones not ringing for incoming calls

Please let us know if it works…

Good luck and have a nice day!


PS: Time for me to go to sleep, it`s past 1 am now… :wink:

Thanks Marbled worked great.

For everyone’s clarity, on FreePBX 12.0, I experienced a fatal SQL CDR error when trying to perform a Reload after a system Restore from my production FPBX server to a vanilla FPBX test server. The Restore sets the CDRDBPASS value to the production server value which unfortunately does not match the password values set in the test server conf files - freepbx.conf and cdr_mysql.conf. The commands line provided by Marbled are:

mysql> use asterisk
mysql> update freepbx_settings SET value = ‘test server new password’ WHERE keyword = ‘CDRDBPASS’;

The information was also useful as it helped my navigate the FPBX schema using HeidiSQL to confirm the changes.

Thanks again!


You are welcome…

I think this should probably be done automatically by the restore because the only time the password in the database will match the one actually used is when someone restore to the same server to restore to an earlier point in time…

If you need to restore to another server or to the same server after a crash or a similar incident you will need to manually change the password in the database as described…

Have a nice day!


I totally agree. I imagine there may a security angle to this problem but a well documented procedure can make the fix rather trivial.


Actually, the problem is that the CDR settings have been set in the first place. If they’re blank, they’re automatically copied from the standard ones in /etc/freepbx.conf

You can fix this yourself by going to Advanced Settings, turning on ‘Show Readonly Settings’ and ‘Edit Readonly Settings’ and remove all entries under CDR.

That’ll let FreePBX know that it should just auto-detect the settings.

1 Like

I’m sorry, can you please clarify? The process I used was to copy a backup to a thumb drive and perform a restore to a brand new installation (no settings changed) of FreePBX of the same version. The restore tripped up on the CDR password mismatch after the restore was complete and a reload was performed. As noted, I have done many many restores in the past and the process was flawless, that’s why I’m posting - must be missing something obvious.

Let me know how I can change the restore process and I’ll give it a try.

I do appreciate the feedback, thanks!

In advanced settings, on your current machine these settings are not blank:

However, to see those options, you need to turn on the two top options ‘Display Read-Only Settings’ and ‘Override Read-Only Settings’.

Hi Rob!

Could whatever the best way to reset the password in the database be automatically done by the restore procedure?

Is there a reason why it is not done automagically (as the OP said possibly security reasons)?

Thank you and have a nice day!


It’s not done automatically because it should be empty, and something’s set it. So the restore process assumes you know what you’re doing, and doesn’t change it.

Restore cares about lots of niggly little things like that, but it explicitly won’t go and change something you’ve changed from default.

Just an update Rob, your procedure worked fine - nice that you can do everything from the gui and avoids the use of SQL which may please some. The location of the settings is a bit obscure - but now I know, I’ll never forget :grin:

Thanks for your help!

1 Like

Hi Rob!

I am pretty sure I had never messed with it (I would have no use to do that) and I had this problem as well…

I have blanked them out and if they are ever set again I will try to track down how they got set…

Thank you and have a nice day!


1 Like

I’ve just stumbled upon this thread… having battled with a warm backup machine for the last couple of days.

I know for certain I haven’t changed the password in the advanced section as the new warm backup machine was a clean install onto a new drive 2 days ago, and I didn’t even know about the buttons to unhide the readonly fields and make them editable until just now!

I eventually fought my way into mysql command line, dumped the freepbx_settings table to a text file and was able to find the table structure and the field names in that…

Once that was over I was able to just use an sql update to fix it…

Of course once I knew the keyword was call CDRDBPASS, and googled with that, I came straight down onto this page! Typical! Once you know the answer you can find a dozen copies!

So I’m going the throw in some keywords to help others…

Warm backup restore failure.
[1045] Access denied freepbx
Access denied for user ‘freepbxuser’@'localhost’
Reload failed because retrieve_conf encountered an error: 1

I’ve now blanked the password from the advanced settings, but if that doesn’t work I think a post-backup sql command script coming on…

1 Like


I just wanted to say your solution is “STILL” saving the day in 2017!!! :slight_smile: I’ve been on this issue for 3hrs and I “just” found the answer through your post 20 mins ago. I had to restore twice, but it finally worked.

Good lookin’ out on this one…