I’ve seen plenty of people run into this and similar issue, but I haven’t been able to find a solution.
The login screen is presented, I enter the correct admin username and password, and then try to login. Several calls are made, and then “Login success” is displayed in the browser console.
One second or so later, the message “Error occurred while retrieving records” is displayed on the login screen, and there’s the dreaded
[HTTP/2 404 Not Found 316ms
How can it first validate my login successfully, and then all of a sudden return a 404 …
Is mod_rewrite up and running? Did you follow the steps described in the installation docs regarding rewrites?
That URL doesn’t look correct to me, although I could be wrong.
Yes on all accounts This was a working 8.3.x installation before, so all of that is verified.
The URL looks strange because of the “suitecrm.local” hostname, but that’s actually OK. The weird thing is that everything loads up and looks fine, until suddenly the API call returns a 404.
What looks strange to me about the URL is that it doesn’t look like an old v7 url, which would be
(note I removed the
and It also doesn’t look like new v8 URL, which would be something in one of these formats:
Well that’s certainly odd But I do see the
/#/Login URL before I click the button. And there are calls to
/api/graphql that succeed. So it’s only the last URL that you list that differ.
DocumentRoot (Apache) to the
/public SuiteCRM folder. The relevant block has
AllowOverride all. The
.htaccess file in
/legacy/ as its
What I don’t get is why it says the login was successful and then it just kicks back with an error (but perhaps that’s due to the failed api call).
If I enter invalid credentials on purpose, it does tell me that they are indeed invalid.
Your configurations appear correct. I guess it’s bugging out somewhere, can you get server-side logs?
Try to find anything relevant at the time that 404 occurs, see
php_errors.log (in the directory specified in your php.ini)
/public/legacy/suitecrm.log shows nothing.
The php_errors.log does show content, but only PHP deprecation notices. No errors.
The Apache error log file shows nothing of interest.
The directory that holds PHP session files is quickly filled with “junk” (session files) even after I clear it and re-start PHP-FPM.
I tried this with PHP FPM 8.1 and 7.4, same result.
And I don’t understand why my fresh install works (also 8.4.0) but this one doesn’t. It’s almost as if there’s something “odd” in the database lingering that triggers bad code.
OK, so THIS is weird. If I point my browser to /legacy/index.php, I’m asked to login and then the login works
I don’t quite understand how … I thought the DocumentRoot in Apache was supposed to be /public … no?
Yes the root is “public”. Maybe your login works that way, but do you get the full SuiteCRM? Or one without the top menus?
You can try cache clean-ups:
The Symfony cache in
The legacy cache in
If you can navigate to the Admin / Repairs screen, try a QR&R and any other repairs that look promising
Your problem is very weird, I must say…
I can only see the dashboard, however, but it’s my dashboard. I cannot get to the admin settings screen.
So, something is obviously still wrong, but I have no clue as to what.
I’ve cleared those, and restarted the PHP process, no change.
I’ve also issed a
bin/console cache:clear, but still no change (the command completes successfully).
I don’t know how I can get to the admin interface. I seem to have to be on /legacy for it to work somehow.
I’m running out of ideas here …
There are ways to run Quick Repair and rebuild from the command-line, in v8 I am not sure if it from Robo (legacy) or from Symfony console.
After that, I can only think of a full PHP debug to get to the bottom of this
What would be the commands for that?
Yeah, I’ve been reading PHP code for a while now trying to figure this out, but SuiteCRM is … quite “multi-layered”