GregoryLMartin's picture

In the Password Management section, there are pulldowns to choose Email templates for Sending Initial Password to new users and for sending a user a Reset Password Email.

Both of these are blank to begin with, but some "canned" choices are available via the pulldown.

However, choosing those Templates and then clicking the Save button has no effect.  When returning to this configuration page, both pulldowns are again showing the "None" choice that was there originally.

As a result, we are unable to add users and unable to retrieve lost passwords.


Please help.

John Mertic's picture

Let us know which version of SugarCRM is this, and if you are self hosting or hosted somewhere else.


GregoryLMartin's picture

We built the server using the Turnkey Linux AMI from the Amazon Marketplace in AWS.  I call that "self hosted", but not sure how you would classify it.

Claude Prüfer's picture

I've encountered the exact same problem. I'm using SugarCRM CE Version 6.5.2 (Build 8410).

Jeremy Davis's picture

Is that right? If so then perhaps we need to get the TKL guys to consider upgrading the SugarCRM version included in the SugarCRM appliance!?

Generally versions of software are not updated in TKL versions but they may make an exception?

We'll need to get in quick though because I know the TKL guys are currently working on a final 12.1 bugfix/update release (prior to moving development to v13).

John Mertic's picture

Can you see any errors in the PHP or Sugar error logs?

pjdurham's picture

I can confirm the same behavior (SugarCE 6.5.3 Build 8410). Neither the Enable System-Generated Passwords check box will stay uncheck nor will the email template choice stay selected from the dropdown menu.

As for the log suggestion - same problem occurs when trying to set the logging level to something other than fatal. That is, when you re-open the page, the log level has automagically been reset to fatal.


This is a permission problem but I hit it with a large hammer so I have no refined suggestions.

Since it seemed to me to be acting like a write-forbidden problem, I chown -R on /var/www/sugarcrm from root:root to www-data:www-data. Then reloaded apache2 for good measure.

Now the change in password enable and email link stays when changed, so too does the logging level.

btw - thanks to all for your efforts

John Mertic's picture

Check to see if a config_override.php file is being created in the root of the directory. I'm wondering if some sort of create permission is blocking it, or if the file isn't able to be written to.

sirius's picture


I was having the same problem with SugarCRM v 13.0 release 28 Oct '13.

I got it fixed with same / similar instructions as per "pjdurham". Thanks :-)

(I don't know what the security permissions are for having changed the permissions on the files and folders, but it's working...)

Here's what I did:

Logged in as root

cd /var/www/sugarcrm (this is where my sugar was lying...)

chown -R www-data:www-data *.*

chown -R www-data:www-data *

Now all files and folders have "www-data" as the owner.

Saving "password reset" settings under permissions now actually works.

Thanks all. Hope it helps a bit.

sirius's picture

Sorry, correction.

I was using Turnkey SugarCRM v 13.0 (Sugar CRM 6.5.11)


Steve Frank's picture

Its upto the software of sugarCRM which is defintly based upon the log server that drive the information, that create valuable data

Cloudways provide you a platform for managed hosting services with wordpress, Alfresco cloud hosting,joomla and other hosting service

Stan's picture

Thanks! I was having the same problem and sirius's solution worked for me!

Nate's picture

I too was having this issue but didn't want to make the mass change recommended here. Instead I found the following document that explains the recommended permissions for the files in the SugarCRM installation:

I ran the following commands in my turnkey linux SugarCRM installation (v6.5.11 Build 8754) and it resolved the problem. The first two commands are just to use the settings recommended by the document and do not actually resolve the issue. It was the third command that finally resolved the issue for me.

chmod 775 /var/www/sugarcrm/{cache,custom,data,modules,include,upload}
chmod 664 /var/www/sugarcrm/{config.php,config_override.php,sugarcrm.log}
chown www-data:www-data /var/www/sugarcrm/config_override.php

The symptom I noticed was that the other two files were owned by www-data but config_override.php was owned by root. Here is what I saw before making the changes above:

-rw-r-----  1 www-data www-data   8449 Mar  4 15:31 config.php
-rw-r--r--  1 root     root          0 Feb 27  2013 config_override.php
-rw-r--r--  1 www-data www-data   5313 Mar  4 16:19 sugarcrm.log

And after the changes above:

-rw-rw-r--  1 www-data www-data   8449 Mar  4 15:31 config.php
-rw-rw-r--  1 www-data www-data    420 Mar  4 16:30 config_override.php
-rw-rw-r--  1 www-data www-data   5785 Mar  4 16:30 sugarcrm.log

Note that I also changed the settings after the above change, so you'll notice that the size of config_override.php changed from 0 to 420 due to the fact that the changes were in fact saved when they had not been previously.

Hopefully this helps someone else along the way.

Jeremy Davis's picture

Thanks for contributing. It might actually be a good idea to add this to the appliance.

wapching's picture

Yes please add this to the appliance. I installed it yesterday and was really getting concerned until I found this thread :-)

Having to mess with permissions after the install, with no direction to do so is kindof, well, un-appliance-like :-D

Thanks Nate!

Jeremy Davis's picture

However, the appliances are generally configured for maximum security (ideal). Unfortunately in some cases this messes with functionality (not ideal). So it is always a trade-off between security and usability.

When an appliance is developed, often the TKL core devs are not totally familiar with the software, so they use installation documents provided by upstream and then on top of that use a 'best practice' security model. Sometimes 'best practice' security means that the webserver account doesn't have write privileges to areas that it might need to provide maximum usability/functionality. So whilst in a perfect world each upstream software would clearly document 'best balance' between security and usability/full functionality, that isn't always the case. Sometimes, even when upstream does document this (as it seems SugarCRM do - as linked to by Nate) the devs don't see it...

So this leaves TKL to take a 'best guess'. All the appliances are tested prior to release, but not always all possible functionality (as you could imagine testing every possible option in every single appliance would take forever...). So if there is ever any doubt, we always err on the side of caution.

This approach sometimes means that permissions (or other minor factors) are not always quite perfect. But we figure that rather than spending heaps of time researching each piece of software (too time consuming for our available resources) and testing each release totally exhaustively (pragmatically impossible), we rely on end users like yourself to assist in this regard.

Once we know what needs to be tweaked, we can ponder that and decide the best course of action. Generally that will result in the next release of the appliance containing said fix...

FWIW though I'm really glad you posted, because I had forgotten about it and have only added it to the TKL Issue tracker!

Bryan Ponder's picture

I just downloaded the VMWARE version of SugarCRM  and it continues to have this exact problem.

Jeremy Davis's picture

This has actually been fixed in the source code (see here) but the new appliance has not yet been released. Soon hopefully...

Add new comment