New SuiteCRM 8 installer doesn't run - browser shows "Forbidden You don't have permission to access this resource"

Hi all, I’m attempting to install SuiteCRM 8 to try out all the cool new features but instead of the installer appearing in my browser I get “Forbidden You don’t have permission to access this resource”.

I am attempting to install on FreeBSD v13 with PHP 8.0.15, Apache 2.4.52 and MariaDb 10.5.13, and using the recommended vhost definition in the installation instructions.

Reveiwing the SuiteCRM v8 php requirements list, I have all modules installed except for “cli” and “common”.

phpinfo reports my server php configure command includes ‘–disable-cli’. However “php --version” reports “PHP 8.0.15 (cli) (built: Jan 22 2022 01:15:46)”, implying cli is present.

“common” appears to be a distribution-specific collection of commonly used modules, and available on at least on REL but not on FreeBSD. My installed modules are listed below. Can anyone say if I’m missing any which would result in the “Forbidden…” error connecting to SuiteCRM 8?

Thanks in advance,

% php -m
[PHP Modules]

[Zend Modules]


Did you run these commands during your setup?

find . -type d -not -perm 2755 -exec chmod 2755 {} ;
find . -type f -not -perm 0644 -exec chmod 0644 {} ;
find . ! -user www-data -exec chown www-data:www-data {} ;
chmod +x bin/console

Section 2.3 on this page - Downloading & Installing :: SuiteCRM Documentation

Yes, I set permissions using the recommended procedure.

Fwiw, I successfully installed the latest SuiteCRM v7 release without issue. I suspect there is some subtle changes in how v8 is served, or perhaps the default apache configuration on FreeBSD that is causing me grief.

Making progress…

  1. replaced “Order Allow,Deny” with “Require all granted” in the Apache vhost definition as I am using Apache 2.4. Configuring a Web Server (Symfony Docs)

  2. installed php80-tokenizer.

After this the installer ran and completed successfully, but after logging in as the new admin user the dashboard reports “Internal Server Error”. The error in the Apache log is:

[Sat Feb 26 17:53:06.910641 2022] [php:warn] [pid 92980] [client] PHP Warning: Attempt to read property "post_type" on null in /usr/local/www/wordpress/wp-includes/class-wp-query.php on line 4273

I found a similar issue report in the forum, I seem to be having the same re-direct issues with home/dashboard and most anything in the Admin dropdown. SuiteCRM8 install issues on FreeBSD/Truenas - #2 by TripitakaBC

@clemente.raposo if this now looks like the same issue, I would very much appreciate your insight.

This is my public/.htaccess

dale@whizzer:/usr/local/www/suitecrm/public % cat ./.htaccess
# Use the front controller as index file. It serves as a fallback solution when
# every other rewrite/redirect fails (e.g. in an aliased environment without
# mod_rewrite). Additionally, this reduces the matching process for the
# start page (path "/") because otherwise Apache will apply the rewriting rules
# to each configured DirectoryIndex file (e.g. index.php, index.html,
DirectoryIndex index.php

# By default, Apache does not evaluate symbolic links if you did not enable this
# feature in your server configuration. Uncomment the following line if you
# install assets as symlinks or if you experience problems related to symlinks
# when compiling LESS/Sass/CoffeScript assets.
# Options FollowSymlinks

# Disabling MultiViews prevents unwanted negotiation, e.g. "/index" should not resolve
# to the front controller "/index.php" but be rewritten to "/index.php/index".
<IfModule mod_negotiation.c>
    Options -MultiViews

<IfModule mod_rewrite.c>
    RewriteEngine On

    RewriteRule ^index.php.*$ - [L,NC]

    # Determine the RewriteBase automatically and set it as environment variable.
    # If you are using Apache aliases to do mass virtual hosting or installed the
    # project in a subdirectory, the base path will be prepended to allow proper
    # resolution of the index.php file and to redirect to the correct URI. It will
    # work in environments without path prefix as well, providing a safe, one-size
    # fits all solution. But as you do not need it in this case, you can comment
    # the following 2 lines to eliminate the overhead.
    RewriteCond %{REQUEST_URI}::$0 ^(/.+)/(.*)::\2$
    RewriteRule .* - [E=BASE:%1]

    # Sets the HTTP_AUTHORIZATION header removed by Apache
    RewriteCond %{HTTP:Authorization} .+
    RewriteRule ^ - [E=HTTP_AUTHORIZATION:%0]

    # Redirect to URI without front controller to prevent duplicate content
    # (with and without `/index.php`). Only do this redirect on the initial
    # rewrite by Apache and not on subsequent cycles. Otherwise we would get an
    # endless redirect loop (request -> rewrite to front controller ->
    # redirect -> request -> ...).
    # So in case you get a "too many redirects" error or you always get redirected
    # to the start page because your Apache does not expose the REDIRECT_STATUS
    # environment variable, you have 2 choices:
    # - disable this feature by commenting the following 2 lines or
    # - use Apache >= 2.3.9 and replace all L flags by END flags and remove the
    #   following RewriteCond (best solution)
    RewriteCond %{ENV:REDIRECT_STATUS} =""
    RewriteRule ^index\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L]

    # If the requested filename exists, simply serve it.
    # We only want to let Apache serve files and not directories.
    # Rewrite all other queries to the front controller.
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^ %{ENV:BASE}/index.php [L]

<IfModule !mod_rewrite.c>
    <IfModule mod_alias.c>
        # When mod_rewrite is not available, we instruct a temporary redirect of
        # the start page to the front controller explicitly so that the website
        # and the generated links can still be used.
        RedirectMatch 307 ^/$ /index.php/
        # RedirectTemp cannot be used instead
dale@whizzer:/usr/local/www/suitecrm/public %

Your php warning there is from WordPress not SuiteCRM, isn’t it?

@aaronh yes, you are correct, my apologies. I must have copied the wrong line in haste, as I am confident I saw the same error posted by TripitakaBC:

…/usr/local/www/suitecrm/public/legacy/.htaccess: RewriteBase: argument is not a valid URL, referer: …

However, now after dropping and recreating the database, I get a blank screen instead of the installer. :frowning: It’s been a long day, I will start over again tomorrow back at the beginning with re-extracting the distribution. Thanks for your help.


Fresh start and the installer completed successfully again. At least that much is consistent. :slight_smile: This time I added a trailing “/” to the URL in the installer, hoping I understood TripitakaBC’s solution but no luck and got “Server Error” again after logging in. Most menus seem to work except for Home and Admin, that give Server Error.

The error message in the Apache log was as I recalled, and this time will copy correctly:

[Sun Feb 27 00:43:06.528377 2022] [core:alert] [pid 49765] [client] /usr/local/www/suitecrm/public/legacy/.htaccess: RewriteBase: argument is not a valid URL, referer:

I compared the …/public/.htaccess posted earlier to the current …/public/.htaccess (after adding a trailing “/” to the URL given in the installer) and they are identical. Reviewing TripitakaBC’s .htaccess again, there seems to have been significant changes made to public/.htacces since that time (Nov 2021), and I’m not knowledgeable enough about Apache re-writing to understand more.

I’m running out of ideas and any suggestions would be appreciated. Is it possible there are more changes required to my apache vhost definition for Apache 2.4?

Hi @dalescott,

I believe you are looking at two different issues here. The first, you solved following the post I made.

The second, is that the rewrite cannot find the URL to

Try opening a console on whatever system you have suitecrm installed on and type:

Make CERTAIN that your suitecrm installation can resolve to that FQDN. The error is suggesting that it cannot which points to a DNS issue, possibly as a result of being behind a reverse proxy.

I can get your login page from here so it seems to be resolving OK. Obviously, I don’t have access to it but I can see the login screen.

Hi @TripitakaBC. You can try logging in if you want. Username “dale” and password “LZY9n3PS6Rqi” (it’s a throw-away password and there’s no data yet in SuiteCRM).

OK, I get the Internal Server Error there after logging in which means we are back to the redirect error I got.

I actually gave up on SuiteCRM as it was to complex for my needs and as a beginner trying to deal with low-info levels on the new v8 release, I moved to EspoCRM which I’m still on. I know way more than I did back then so I may move back to SuiteCRM in the future. I share that just to give some insight that I’m not 100% up to date on current SuiteCRM.

It looks like you are running FreeBSD so I wonder if you are building this in a TrueNAS jail? If so, I have some build scripts I can share because I must have rebuilt that jail 20 times trying to resolve the issue and the scripts build it in about 2 minutes.

If I recall, I may have ended up on PHP74 due to issues with PHP80. I see you are on PHP80 so may be worth a try.

@TripitakaBC I missed your first reply. Reponse to curl seems to indicate is resolving. Fwiw I’m using for DNS and have separate domain entries for a number of vhosts. The other vhosts all use SSL with Letsencrypt certs. I created and installed a Letsencrypt cert for with certbot, and all worked ok with SuiteCRM v7. I then disabled SSL (commenting relevent lines in httpd-vhosts.conf and httpd-vhosts-le-ssl.conf) while trying to install SuiteCRM v8. At first it seemed Chrome would sometimes access SuiteCRM using SSL, but I attributed it to my SSL/non-SSL experimenting and it stopped after I cleared the cache in Chrome.

dale@whizzer:~ % curl
<!DOCTYPE html><html lang="en"><head>
    <meta charset="utf-8">
    <base href="">

    <meta http-equiv="cache-control" content="no-cache, must-revalidate, post-check=0, pre-check=0">
    <meta http-equiv="expires" content="0">
    <meta http-equiv="pragma" content="no-cache">
    <meta name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1">

    <link rel="manifest" href="site.webmanifest">
    <link rel="icon" type="image/x-icon" href="dist/themes/suite8/images/favicon.ico">
<style>:root{--blue:#007bff;--indigo:#6610f2;--purple:#6f42c1;--pink:#e83e8c;--red:#dc3545;--orange:#fd7e14;--yellow:#ffc107;--green:#28a745;--teal:#20c997;--cyan:#17a2b8;--white:#fff;--gray:#6c757d;--gray-dark:#343a40;--primary:#007bff;--secondary:#6c757d;--success:#28a745;--info:#17a2b8;--warning:#ffc107;--danger:#dc3545;--light:#f8f9fa;--dark:#343a40;--breakpoint-xs:0;--breakpoint-sm:576px;--breakpoint-md:768px;--breakpoint-lg:992px;--breakpoint-xl:1200px;--font-family-sans-serif:-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,"Helvetica Neue",Arial,"Noto Sans",sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Noto Color Emoji";--font-family-monospace:SFMono-Regular,Menlo,Monaco,Consolas,"Liberation Mono","Courier New",monospace;}*,:after,:before{box-sizing:border-box;}html{font-family:sans-serif;line-height:1.15;-webkit-text-size-adjust:100%;-webkit-tap-highlight-color:transparent;}body{font-family:-apple-system,BlinkMacSystemFont,Segoe UI,Roboto,Helvetica Neue,Arial,Noto Sans,sans-serif,Apple Color Emoji,Segoe UI Emoji,Segoe UI Symbol,Noto Color Emoji;font-size:1rem;font-weight:400;line-height:1.5;color:#212529;text-align:left;background-color:#fff;}body{height:100%;margin:0;padding:0;border:none;background:#f5f5f5;}</style><link rel="stylesheet" href="dist/styles.77da3e898457fbaaee33.css" media="print" onload="'all'"><noscript><link rel="stylesheet" href="dist/styles.77da3e898457fbaaee33.css"></noscript></head>

<script src="dist/polyfills-es5.4ac9e0b975194dde5c28.js" nomodule defer></script><script src="dist/polyfills-es2015.72528892cc7709ea2d41.js" type="module"></script><script src="dist/main-es2015.e204a829473fb71d849f.js" type="module"></script><script src="dist/main-es5.e204a829473fb71d849f.js" nomodule defer></script>

</body></html>dale@whizzer:~ % ls /usr/local/etc/apache24/extra/httpd-vh*

Thanks @TripitakaBC for confirming as much. I’m running SuiteCRM on baremetal FreeBSD v13 with PHP 8 (not in a jail). I will try upgrading to PHP 8.1 when I get a chance.

Thanks also for reference to EspoCRM. SuiteCRM is more CRM than I also need, but it’s the Projects module I’m really interested in. My primary focus is helping hardware startups manage parts, bills of materials and supply chain, accelerate new product introduction and scale production. I’ve investigated other web-based open source project management software and they have either been too simple (e.g. Nextcloud Deck) or too complex (e.g. OpenProject, ]project-open[, projeQtOr). The Projects module in SuiteCRM looked like it might be just right.

Startups generally also need to migrate from email contacts and spreadsheet CRM to something more formal, and I could offer SuiteCRM as another arrow in my quiver so to speak.

Thanks for the PM, I’ll ping you there.

If anyone has any other suggestions, I’m all ears. :wink: TIA

Solved! I re-installed from scratch again, but this time I used the complete URL in the installer ( and “” for host address instead of “localhost”. After logging in the first-time wizard ran successfully (which it hadn’t before, only “Server error”). I then re-enabled the SSL re-writing generated by Certbot and re-installed one more time using as the site URL and the installer ran correctly again.

To summarize, compared to the V8 installation instructions, I

  • replaced “Order Allow,Deny” with “Require all granted” in the Apache vhost definition for Apache 2.4
  • installed php80-tokenizer (note that dom is also required, although not included in the installation instructions)
  • in the installer, I used the complete URL with protocol for the SuiteCRM instance (
  • also in the insaller, I used “” for the Host Name instead of “localhost”

Everything isn’t perfect yet however. I uploaded a photo to my user profile but it’s not getting displayed. I’ll troubleshoot a bit more and open a new topic if needed.

I was able to get this to work on CentOS7, Apache, PHP 7.4, But I had to do the following:

  1. Make sure that the MySQL DB and User allow all connections

  2. Add to public/.htaccess
    php_value error_reporting 2039
    php_value upload_max_filesize 64M
    php_value post_max_size 64M
    php_value max_execution_time 300
    php_value max_input_time 300

  3. I use open_basedir restrictions, so I had to add to the virtual host file:

php_admin_value upload_tmp_dir /path/to/user/tmp
php_admin_value sys_temp_dir /path/to/user/tmp
php_admin_value open_basedir /path/to/user
php_admin_value session.save_path /path/to/user/tmp

  1. Also had to add to the virtual hosts file Directory settings:

Options FollowSymLinks MultiViews
AllowOverride All
Allow from All
Require all granted

  1. I also add the to the /etc/hosts and resolved it to the IP of the server

  2. I also updated all composer files before installing. I did this by using Composer and then doing a “php ./composer.phar update” and then “rm composer.phar” to clean up.

  3. I edited the public/legacy/config.php and placed the following at the top:


After doing all of that, I was able to finally get this working. Took 5+ hours if farting around.

Hope this saves someone some time.