Category Archives: SugarCRM

This is the one product that is php based open source that I have worked with on a Windows platform. Normally I would use Linux but this eased the interfacing as we used MS-SQL instead of MySQL.

sugar_file_utils.php Fatal error: on migrating SugarCRM

[text]Fatal error: sugar_file_put_contents_atomic() : fatal rename failure ‘/tmp/tempI3QakJ’ -> ‘cache/modules/Employees/Employeevardefs.php’ in /home/account_name/public_html/sugarcrm/include/utils/sugar_file_utils.php on line 187

It’s a permissions thing. Setting up a new server to migrate SugarCRM. The new install of Sugar appears ok until I update the config.php file and then it breaks.

The trigger is the permissions on the second named file


Just for clarity the line 187 that is referenced is in this function in SugarCRM

180 if (!@rename($temp, $filename))
181 {
182 @unlink($filename);
183 if (!@rename($temp, $filename))
184 {
185 // cleaning up temp file to avoid filling up temp dir
186 @unlink($temp);
187 trigger_error("sugar_file_put_contents_atomic() : fatal rename failure ‘$temp’ -> ‘$filename’", E_USER_ERROR);
188 }
189 }

The error is triggered when line 183 fails to rename the temp file as the cache file. Permissions on the temp directory must be ok or the creation of the temp file would have triggered an earlier error. It is also unlinked (deleted) successfully which means that at line 186 the temp directory/file permissions are ok. So it must be the cache directory at issue.

In this case the cpanel server was allocating the user account as both owner and group. Sugar apparently wants to see Apache as the group, or at least the Apache account owner, ‘nobody’. So while the chmod settings for owner and group read/write were ok, the group was incorrect.

#chown -R owner:nobody sugarcrm/

Command for the ownership change for the group to nobody.

Edit: As correctly pointed out I had used chmod when I manually typed up the instructions. Corrected the above to read chown. Thanks Derek.

SugarCRM, IIS7, PHP and configuring php.ini

Seems that every time I look at a SugarCRM on Windows installation it is a case of the devil being in the details.

Windows 2008 server can be painful at times. Granted it is locked down by default to protect us from the more informed black hats that may get into our systems, but sometimes it just makes it hard to do work.

This time the Sugar install was done by others and it worked except that the Sugar pages were blank. That is the login page worked and the headers and menu bars in the pages were ok, but the Home page, Accounts, etc did not display anything, i.e blank pages.

So I started at the basics and checked the PHP configuration:

  • Set post_max_size to at least 60MB
  • Set upload_max_filesize settings to at least 60MB
  • Set max_input_time to a large number
  • Set memory_limit to 256MB

Then check for PHP in the path environment variable and the PHPRC variable set. I have written up the details of that in another post on IIS7 and PHP 5.3.x

The Sugar installer can be re-run to use it’s System Check to confirm the write permissions without losing anything. Change the sugar config.php file setting ‘installer_locked’ => true to ‘installer_locked’ => false and run the install.php file. This will prompt for some settings but the system check comes before anything else.

In this case the System Check page identified that most directories were not writeable. So I made some changes as per below and clicked the ReCheck option on the System Check page to confirm that the directory was fixed.

Setting write permissions to the various directories within a Sugar install on a linux server is pretty straight forward with assigning Apache or the account that Apache runs as the write permissions. Windows is similar except that it can be obscured depending on how detailed the sysadmin was when configuring the server accounts.

By default granting permissions to the local machine IUSR account should get it working. Start by adding the IUSR account as default Read type permissions to the entire Sugar directory. Access this from the directory Properties -> Security tab.

Then add specific Modify (Full control is not needed) access to the cache, custom, modules, and upload directories level which should automatically include the subdirectories and files by default.

Check each of the directories that the Read-Only flag is unchecked on the General Tab of the properties window.

Once you have the write permissions correct and the systemcheck gives the go ahead, just edit the config.php and set ‘installer_locked’ => true again. Close the install script without proceeding and run Sugar again. In this case I had been successful and Sugar was doing exactly as it should.

Windows IIS 7 removing PHP 5.2.8 and installing PHP 5.3.8

Seems like a simple enough task.

Remove the old PHP 5.2.8 and update via the Official Microsoft site a brand new 5.3.8 PHP version.

Never, never, ever assume!

For those of you that prefer a quick summary the removal of the PHP 5.2.8 via the Uninstall process does not remove / reset the environment variables of PHPRC or PATH. Further it does not remove the Fastcgi settings in the IIS console. Using the Microsoft Installer for PHP on Windows 2008 server does not adjust the environment variables for the new path and does not overwrite but adds new entries into the IIS configuration. The really painful and most time consuming issue was that the installer for Microsoft does not automatically include extensions for MS-SQL, only MySQL !!!

The slightly longer version with links and details follows. Suffice to say at this point if you have found this whilst trying to install SugarCRM, PHP 5.3.8 to work with Windows Server 2008 and IIS 7 then it really is relatively simple once you get past the ‘I would have expected that……’ thought process.

Use the Windows Installer for PHP the current one is 5.3.8 If you dont have the Web Platform Installer it will trigger that installation first. There is information on the learniis pages that provides more detail.

Modify the environmental variables – if upgrading remove / modify the existing – for a first time install add the PHPRC if necessary.

Control Panel -> System and Security -> System -> Advanced System Settings -> Environment Variables

Select in the System Variables lower panel not the User Variables in the upper panel.

Insert the path, in my case it is C:Program Files (x86)PHPv5.3, to the PHP installation as the first element in the Path command. This saves the system from trawling through all the other application paths and adds minimal overhead for the other applications as there are only a relatively small number of files to check in the PHP directory.

Insert the PHPRC variable and set the same path C:Program Files (x86)PHPv5.3

To test that this is working open a new command window (Start -> Run -> cmd: but if you need this you probably are out of your depth!) and type php -v at the prompt. You should get back a PHP 5.3.8 information text. If you get a not found error then you need to check your install and variable paths actually match.

In the IIS console at the server level open the Handler Mappings icon and confirm that there is only one PHP entry – default should be PHP53_via_FastCGI. Remove any other PHP entries.

In the IIS console at the server level open the FastCGI icon and confirm that there is only one entry there as well. Remove any other than the 5.3.8 entry. There should be only one.

At this stage the IIS console should show a PHP Manager icon in the server page. Checking the phpinfo() page will confirm that PHP is running ok.

The next bit is what caught me. It was an existing SugarCRM -> MSSQL install that was working (albeit with other issues) but I kept getting Error 500 Internal Server Errors when I tried to run the old Sugar install. Using phpinfo() pages worked so it was not a PHP issue. There was no PHP error log message, and nothing in the Event Viewer.

It was only during some testing that I tried installing a fresh copy of SugarCRM to establish if the issue was something corrupted in the existing application. The installer ran through its checks and offered for me to select the database driver. But, the only option was MySQL. That was my Duh! moment. Checking back on the PHP install and doing some extra reading confirmed that the earlier 5.2.8 install had the MS-SQL drivers while the 5.3.8 doesn’t automatically include them. You would think that a Microsoft prepared installer would have MS-SQL as a preferred database, but no it’s a separate install. Which explains the odd Internal Server Error 500 when trying to use the SugarCRM application. It could not get to the database as the PHP drivers did not exist.

Refer to the learniis page for installing the SQL Drivers but it points to v1.0 of the drivers. Use the following link for version 2.0

Downloading the Microsoft SQL Server drivers for PHP currently version 2.0.

Select the correct .dll for the installation, VC9 Non-Thread-Safe, for both the SQL and PDO_SQL (PHP Data Objects) and copy these to the PHP extensions directory C:Program Files (x86)PHPv5.3ext

Finally, using the IIS console PHP Manager at the server level, enable these additional extensions. I restarted the IIS for good measure and SugarCRM is working again.

SugarCRM IIS 7.5 PHP Windows Server Exchange combined

When combining server roles to perform many tasks with one server there is a lot of potential for things to trip over themselves.

This started as a simple ‘Provide an LDAP connection between SugarCRM and Active Directory’.

Issue: Configuring the LDAP settings for SugarCRM is relatively easy but when trying to test by setting a specific user to ‘Use only LDAP Authentication’ the SugarCRM login page reports that the LDAP extensions are not loaded. Ok, so its a PHP config issue.

Issue: The PHP error log shows that not only is LDAP an issue but also CURL and a few other PHP extensions are not loading. With a ‘File not found’ error.

The extension files are all there, the paths are correct, etc. The issue appears to be that some supporting files are missing including libeay32.dll and ssleay.dll, so preparing a fresh install of PHP with these options enabled adds the files to the PHP directory. But the error persists.

Issue: PHP 32 bit not 64 bit so we need to set the Application Pool to allow for 32 bit applications. But this triggered another series of issues.

Issue: Attempting to set 32 bit for any App Pool on the server crashes with errors.
The browser returns an error 500 Internal Server Error.

The Application Event Viewer showed

Log Name: Application
Source: Microsoft-Windows-IIS-W3SVC-WP
Event ID: 2282
Task Category: None
Level: Error
Keywords: Classic
User: N/A

The Module DLL ‘C:Program FilesMicrosoftExchange ServerV14Binkerbauth.dll’ could not be loaded due to a configuration problem. The current configuration only supports loading images built for a x86 processor architecture. The data field contains the error number. To learn more about this issue, including how to troubleshooting this kind of processor architecture mismatch error, see

Which led me to Chris’s Blog and issues with setting 32 bit apps on an OWA server. Following those instructions which can be summarised as follows:

  • Stop the IIS Service
  • Edit C:WindowsSystem32inetsrvconfigapplicationHost.config
  • Edit the following 3 lines to append/insert the preCondition=”bitness64″ option
  • <add name=”kerbauth” image=”C:Program FilesMicrosoftExchange ServerV14Binkerbauth.dll” preCondition=”bitness64″ />
  • <filter name=”Exchange OWA Cookie Authentication ISAPI Filter” path=”C:Program FilesMicrosoftExchange ServerV14ClientAccessowaauthowaauth.dll” enabled=”true” preCondition=”bitness64″ />
  • <filter name=”Exchange ActiveSync ISAPI Filter” path=”C:Program FilesMicrosoftExchange ServerV14ClientAccesssyncbinAirFilter.dll” enabled=”true” preCondition=”bitness64″ />
  • Start the IIS Service
  • Set an Application Pool to use 32 bit Applications
  • This resolved the 32 vs 64 bit war and brought me back to the PHP issues that started this.

    Issue: Curl and other extensions not loading.

    So I tried running php from the command line

    D:Applicationsphp> C:progra~1phpphp-cgi.exe
    PHP Warning: PHP Startup: bz2: Unable to initialize module
    Module compiled with module API=20060613, debug=0, thread-safety=0
    PHP compiled with module API=20060613, debug=0, thread-safety=1
    These options need to match
    in Unknown on line 0
    PHP Warning: PHP Startup: Unable to load dynamic library ‘C:Program Files (x86
    )PHPextphp_curl.dll’ – The specified module could not be found.
    in Unknown on line 0
    PHP Warning: PHP Startup: dba: Unable to initialize module
    Module compiled with module API=20060613, debug=0, thread-safety=0
    PHP compiled with module API=20060613, debug=0, thread-safety=1
    These options need to match
    in Unknown on line 0

    So this suggests that it is not a missing file or path but the thread-safety option which is weird as everything I have read including the name of the download is ” PHP Non-Thread Safe” so why would the installer be installing a modules compiled differently to the PHP install? I will probably never know. I gave up at this point and removed PHP 5.2.8 completely and installed 5.3.8 via the Microsoft Installer for PHP which enabled curl and ldap but led to a whole different world of pain.