I just installed SuiteCRM 8.2 and the home like this (see below). Any idea why?
Pages like Account, Contacts, etc. appear to load fine.
The emails page looks broken as well.
I’m using php 8.0
Trying Quick Repair & Rebuild now. We’ll see how it goes 
Maybe something wrong with 2.3 Set permissions
1 Like
I don’t appear to have permissions for this on my shared account. Is there anything I can do through FTP?
You can try to override permissions in FTP right click CHMOD and select including subfolders and files. But it will take a long time.
Thanks for your input. My confusion was that I set permissions using the ### format, whereas the documentation referenced 2755 and 0644 .
I found out that the crm directory should be 755, then I modified the subfolders and files to 757.
The CRM looks great now!
1 Like
Is that a typo, or did you really set them to 757?
That last 7 is a big security problem, you really shouldn’t do it.
Thanks for the heads up. This is what I found throughout the forums.
Should I keep it at 755 now?
Any reason not to follow the recommendations given in the installation page?
If I tried them and it didn’t work, please explain better what you did.
The typical stumbling point is getting the username right. It needs to be the user that your web server is using to run.
I installed this on my webserver and the only method I have is to use 757, 755.
Reading through the forum, a recommendation was 757 on subfolders and that worked.
I’ll change it to 755 and see if it works.
Where is that recommendation for 757? We should remove that or at least warn people.
From those 3 digits, only one will get used. That will depend on the ownerships, which always go hand in hand with permissions.
I always leave the 3rd digit at 0 (no point in giving “world” access).
If your 3rd digit is making a difference for you, that is a clear sign you have your ownerships messed up, because the only way your web server is able to read the files it needs to read, and write the files it needs to write, is to access through a door labeled “anyone can come in and do whatever they want in my server”. Not good.
Lock your doors, and make sure you give your web server user a proper key.
This means: determine which user your web server is running under (you can find it in Admin / Schedulers, in the crontab instructions at the bottom).
Use chown to make that user the owner of all your SuiteCRM files and directories.
Then you won’t need that third digit to get access.
I went back to check my permissions and found out that I set it to 775, not 757 - I just remembered it wrong. My apologies.
That should clear things up.
1 Like
I set it to 775*** not 757
I have had this issue when the public/legacy/themes/suite8/css/Dawn/style.css doesnt exist, if you see a 404 for this file, that may be the issue.
See Developer Install Guide :: SuiteCRM Documentation step 3, in installation for how to fix
I was struggling with the same problem there is another way you can set permissions of all the files and folder instead of using SSH or FTP
copy and paste this code in filename.php and save it in public folder
then run this by websitename/filename.php
<?php
function setPermissions($dir) {
// Change the directory permission to 755
chmod($dir, 0755);
// Open the directory
if ($handle = opendir($dir)) {
// Read all items in the directory
while (false !== ($item = readdir($handle))) {
// Skip the current and parent directory references
if ($item != "." && $item != "..") {
$path = $dir . "/" . $item;
// If the item is a directory, recursively set permissions
if (is_dir($path)) {
// Recursively change the permissions of the subdirectory
setPermissions($path);
} else {
// Change the file permission to 757
chmod($path, 0757);
}
}
}
// Close the directory handle
closedir($handle);
}
}
// Path to the SuiteCRM directory
$suiteCrmDir = '/path/to/SuiteCRM';
// Set permissions for the SuiteCRM directory and its contents
setPermissions($suiteCrmDir);
echo "Permissions have been set.";
?>
757: that would be
- owner: read write execute
- groups that have permissions on the file: read - execute
- the rest of the freaking world: read write execute
now, consider the rest of the world being able to execute a remove root directory command 
please be safe when setting permissions
#!/bin/sh --
Anything malicious here!
1 Like
THIS!
Also, most often it’s ownerships that need to be set again, not permissions. It’s only when people forget (or misunderstand) ownerships that they end up with solutions giving “world” access (that third digit with a 7).