This happpens everytime I install SuiteCRM 😱

which is that I’m getting stuck on the installation screen and SuiteCRM doesn´t accept the database/database user password and it is quite frustrating. I know the information is correct.

and the error is always the same:

#0 /var/www/vhosts/ mysqli_connect()
#1 /var/www/vhosts/ MysqliManager->connect()
#2 /var/www/vhosts/ checkDBSettings()
#3 {main}
  thrown in /var/www/vhosts/ on line 322
[19-Apr-2024 14:29:14 Europe/Gibraltar] PHP Fatal error:  Uncaught mysqli_sql_exception: Access denied for user 'crmuser1234'@'' in /var/www/vhosts/
Stack trace:

which is that the DB user is refused to connect to the database.
I’m also speaking this from experience as I seen this on several different servers we used over the years and I just cannot get my head around why it is doing this.
Sometimes I have solved it by using very simple less complex passwords or/and username on DB user and DB name SuiteCRM. But in overall it is VERY frustrating. I never figured out if this is a bug that never has been fixed in SuiteCRM, but overall it is a common problem that never has gone away.

Checking the install.php log also confirms the same.

Any thoughts?

Thanks in advance.

Can you login with those same credentials from the command-line?

mysql -u yourUsername -p

(it will ask you for the password)

Hi @pgr :smile:
Thanks for your reply.

Yes, I can.

So it is SuiteCRM that keeps trolling me.

This time I am really stuck.

I have tried most of my common tricks to get around this and I have ran out of ideas.

Appreciate any ideas/help to get around this (bug?).

Maybe I should download an older installation package and start all over? :thinking:
(No guarantee though, because the issue is there also in the older install packages).

Thanks a bunch!

Or maybe you could check your config.php file for the database configuration and another way is by updating your admin password using the terminal

mysql -u USERNAME -p

Compatibility Matrix for v8.x

Hi @rsp
There is no config.php file the the www directory as it is generated automatically when you run the installation guide / generated during the installation process.

I dunno. Maubr you could trick the installation process if I take a config.php file from on of our other existing/running SuiteCRM installations on our server and manually edit it and then add it to the current SuiteCRM install www directory. :thinking:

I guess I could try that and see it I can trick SuiteCRM to accept it and allow me to finalize the installation process. Not sure if that will work or cause new issues because the installation process will try to write and create the first config.php in the same directory.

I think if you’re using the linux OS, you can find that file at the below location.


Yes, I had “successfully” installed the 8 version on this instance for a client, but it did give me issues to with “undefined” errors popping up due to SuiteCRm didn’t like the file permissions (Downloading & Installing :: SuiteCRM Documentation) even though I had set the correct ones. So I tossed in the towel today and went back to SuiteCRM 7.X because it gives you less headaches.

in the older version 7.x you do not need to point the www directory to “public” but works out of the box, while 8.x you do need to point www directory to “public” which gives you issues with the server needs permissions to read the files above the “public” folder for it to work.

Oh I didn’t know that I am happy with 7.x version now. :sweat_smile: :sweat_smile: :upside_down_face: I did not update it to 8.x

1 Like

I wonder if you could be having a problem with some auto-complete saved in your browser. Can you try the installer with a different browser, see if that makes any difference?

Other than that, I would suspect a bug in SuiteCRM with some special character in your password.

Try a simpler db password, 8 characters long, with only letters and numbers.

I’ve tested with two different browsers so far (Brave / Google Chome). No change.

I have even tried with a silly password e.g. >>> 123456 = fail.

Yes, that has been my go to solution to this issue in the past and then after the installation completes change it to a more secure complex password. :man_shrugging:

Yes, 8.x is more complex and brings more issues it seems, while 7.x is more straightforward with the exception of the darn installation process which seems to always troll with me. So if you’re happy with 7.x don’t upgrade. :upside_down_face:

Well yep, finally I got it working - after some more testing /fiddle around with various compos of DB name and user PW - and when I set the DB user PW to under 8 characters and only numbers it suddenly worked.

I downloaded an older version of SuiteCRM >>> >>> and unzipped that to the server.

Also the DB name is limited to only 12 characters with only lowercase characters. After that; SuiteCRM suddenly wanted to play along.

Very annoying indeed, but at least I got it installed finally after using several hours on it.

@rsp as you can see in the screenshot the config.php is is first generated during the final stage of the installation process - so prior to that you cannot edit any config.php file. :upside_down_face:

I hope SalesAgility can look into this bug in the near future and hopefully fix this. Its been around for years…

Just my 5 cents though… :thinking:

Now onwards t o the next part which is setting file/directory permissions as SuiteCRM doesn’t seem to like the default 755 (folders)/644 (files) ones. Never understood 100% why it does that:

Thanks guys! :facepunch: :heart:

I don’t think there is any issue on Github with a specific screen, and a specific password that doesn’t work. It seems simple enough, but if those specifics aren’t there, it’s not reproducible, and the issue goes nowhere.

1 Like

I just know that I have experienced this same issue over and over again in the past with 5 different servers we had. But if others can’t reproduce the issue its of course hard to figure out what the actual bug is.

Maybe the bug is that SuiteCRM loves to troll me specifically ha ha? :joy:

I have no clue though…

It sounds like it was consistent, so it deserves to open a new issue on github, with full details of your server OS and version, db type and version, PHP version, Suite version, and steps to reproduce it, to investigate, and hopefully find and fix.