SuiteCRM 8.0.1 installation problems

I’ve come back to give SuiteCRM another try after a few years, but I am having some installation issues. As far as I think the webserver is set up correctly - no errors appear and mod_rewrite is used on other sites on the same server but I cannot get an installation to work properly…and I think it may be to do with the rewrites.

First attempt was to use the installation web page and there are issues with that. Webroot is set up to be the ./public folder under the Suite CRM directory when everything has been unzipped. Following the instructions to the letter, just going to the page does not work - it results in redirects to (so some form of redirect is working).

Alternatively going to the page does not work properly - it is an ‘unstyled’ page where the CSS and Javascript don’t work. Thus “Accept” terms checkbox and language select do not activate the “NExt” button.

I tried the ./legacy/install.php page and that works - well it is styled properly - and allows me further through. However, the next page fails with database credentials being incorrect. They aren’t - I am able to connect through the mysql cli inteface with the same credentials.

I then tried the CLI install route and have got a lot further. THe database is connected and the tables are created and the install finishes with no errors, but when I try and access the site it fails with the user login redirect page which does reports too many redirects.

THis is on CentOS 8 and the SuiteCRM version is 8.0.1.

On CentOS I would check if selinux is blocking anything.

Try disabling it temporarily to see if it changes behaviours.

SE Linux isn’t running - and I have checked again to make sure - sestatus returns ‘disabled’.

Thanks for the response though. :slight_smile:

OK. Next, you can check existing posts here in the forums regarding SuiteCRM 8.0 installation issues, particularly those mentioning .htaccess changes.

Thanks @pgr - nothing regarding .htaccess in the forums seems to relate to my problem…so I have been doing some more investigating to try and track down the issue.

I have removed the .htaccess in the ./public folder for the moment and have traced the code through the index.php and the various includes.

The code traces through to ./public/legacy/include/entryPoint.php without any trouble. Echoing out variables and the getcwd() value (to check I am where I think I should be) all work as expected. However, on line 62 of entryPoint.php and although I am in the right location, the install.php never runs. I have tried forcing the right path by hardcoding it and install.php is never reached.

I cannot work out why. If I issue an echo on line 61 and exit(); that runs. But if I allow line 62 to run, it never does. I have edited the install.php file and added an echo and exit(); to indicate the file has been reached but it never executes the line. Instead it is picking up a redirect from somewhere, and I don’t know where from - it is trying to get to “/#/users/login” with a browser “redirect problem”. As I said .htaccess is disabled and I don’t know where this instruction is coming from.

Any ideas anyone?

Hello Simon,

Just a thought on something I had on a test installation is to double check the site_url and host in legacy/config.php and/or config_override.php

Thanks @shad - I don’t have a config.php in the ./legacy folder. I do have config.php files deeper with the folder structure but they all appear to be for specific areas rather than general setup.

config_override.php does not exist anywhere within the code extracted from the zip file.


config_override.php doesn’t need to exist, you just add it if necessary.

I think the correct location of config.php is public/legacy, not just public

Makes no difference.

Have you been checking both logs, or just one?

Actually, Suite 8 even adds some logs to the list :slight_smile:

Also, please check that your session.save_path directory (as defined in the relevant php.ini) is writeable by the web server - login issues sometimes come from this.

This is frustrating. I have checked the logs and nothing is being written. However, I not surprised (for the suitecrm.log) as I don’t think the installer is getting far enough through the process. It isn’t an issue with trying to log in, it is an issue with the installation process. I cannot get through on the web interface past the include /public/legacy/include/entryPoint.php - that file fails to load at all as the weird redirect happens first, even though .htaccess has been ‘removed’.

I will try the CLI installer again and see if it gets any further.

Hi @simondawson,

Thank you for trying out SuiteCRM 8. And sorry for the delay in replying to this thread.

I know there has already been some back and forth on this thread. I don’t want to abuse of your patience. But it would help if we could get back to the start.

Some questions to try and understand the problem

  1. Which php version are you using?

  2. You are using apache, right?

  3. When you tried the “web installer” did you see this screen?

  4. If you were able to see the above, did the install went ok, and sent you to the login page?

Depending on the above I might have some more questions.

Hi @clemente.raposo
That’s not a problem - thanks for picking up the thread.
PHP v7.3 on Centos 7.9.209 running Apache 2.4.6 and MariaDB 10.4.22 under Webmin/Virtualmin. Server is up to date with all latest patches. All requirements have been met (I believe).

The ./public folder within the SuiteCRM folder structure is the DocumentRoot.

Haven’t seen that screen (only in the docs) - if I go to the domain once unzipped and permissions have been set, the page wants to redirect to

Trying various things out, I have tried going to but that brings up a simple form based page, that is unstyled and the javascript doesn’t work as I can get no further:

As I have said earlier - makes me think that there are some weird redirects in play, but having disabled the .htaccess, I dont know where they are being picked up from.

If I go to htps:// I get a properly styled form to accept the license etc and can move through to a pre-install check and then the basic initial config screen. These two screens, license page and config page, are not in tabs as in your screenshot, but are two separate pages. Filling in the configuration data results in the database credentials not being acceptable…but I know they are and they do work in the CLI installer.

Giving up on the web interface, I have tried the CLI installer and that runs successfully, all the tables are created in the DB and no errors are reported.

However, when I go to the URL I get the same redirect to ./#/users/login which fails with a “The page isn’t redirecting properly” browser error.

Any pointers you may have would be most welcome.

Hi @simondawson,

Thank you for the detailed info.

ok, going with the cli install seems a good idea.

Some more questions:

  1. Did you delete all the .htaccess files? or are they there at the moment?

    • Could we try adding those back please?
      • You should have one in public and one in public/legacy
  2. How does your vhost look like? Something like the following?

    • The following assumes that your SuiteCRM 8 root folder is /var/www/html
<VirtualHost *:80>


        DocumentRoot /var/www/html/public

        <Directory /var/www/html/public>
            Options +Indexes
            AllowOverride All
            Order Allow,Deny
            Allow from All
            Require all granted




I am having an issue with the installation. I have checked multiple times and it gives me this error while all the details are correct:

Database Connection Error: The provided database hostname, port, username, and/or password is invalid.

I’m using PHP 8.0.14 on Ubuntu 20.04.1
MySQL version is 8.0.27

Looking forward to it.

Hi Clemente
I have rerun a complete installation and both .htaccess files are in place.

My httpd conf is:

DocumentRoot /home/.../SuiteCRM/public
DirectoryIndex index.html index.htm index.php   
<Directory /home/.../SuiteCRM/public
    Options +Indexes +IncludesNOEXEC +SymLinksIfOwnerMatch +ExecCGI
    allow from all
    Order Allow,Deny
    AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
    Require all granted

I have tried the AllowOverride with just “All” as well and it makes no difference.

I have also checked the PHP error logs and nothing is written. I have also looked in the suitecrm.log and the following lines may be of interest:

Thu Jan  6 10:59:52 2022 [21092][1][FATAL] User update error: Temp User is not retrieved at ID 1, boolean given
Thu Jan  6 10:59:52 2022 [21092][1][FATAL] Email address save error

The user that I included in the CLI install has been created in the DB and does have an ID of 1.

Any more ideas?

Hi @simondawson,

Thank you. After this re-installation what do you get? The page isn’t redirecting properly?

Hi @Prafull_Satasiya,

It seems like the system is not able to connect to your db.

Could you check the following logs please?

  • logs/install.log
  • public/legacy/suitecrm.log

Hi @clemente.raposo

Chrome gives something similar:


I have cleared out the cookies and it makes no difference

@clemente.raposo Thanks for your prompt reply.

  • logs/install.log

    [2022-01-06 11:46:45] install.INFO: Running step: check-install-lock [] []
    [2022-01-06 11:46:45] install.INFO: step: check-install-lock | status: done [] []
    [2022-01-06 11:46:45] install.INFO: step: check-install-lock | messages: [] []
    [2022-01-06 11:46:45] install.INFO: Installer not locked. Proceeding with install [] []
    [2022-01-06 11:46:45] install.INFO: step: check-install-lock | debug: no debug info [] []
    [2022-01-06 11:46:45] install.INFO: Running step: check-db-connection [] []
    [2022-01-06 11:46:45] install.INFO: step: check-db-connection | status: failed [] []
    [2022-01-06 11:46:45] install.INFO: step: check-db-connection | messages: [] []
    [2022-01-06 11:46:45] install.INFO: Could not connect to db [] []
    [2022-01-06 11:46:45] install.INFO: step: check-db-connection | debug: no debug info [] []

  • public/legacy/suitecrm.log is blank.