"Fatal Error in PHP.rename();" Can't save anything to config.php even when it's 777

MaxD

Hi guys,

I'm running 2.0.18.9 and I'm having this serious issue here. Whenever I'm hitting a save button anywhere in the backend, this message pop-ups. (see screenshot attached)

Fatal Error in PHP.rename();

rename(/tmp/configi0Ks7l,/opt/bitnami/apps/vanilla/htdocs/conf/config.php): Permission denied
The error occurred on or near: /opt/bitnami/apps/vanilla/htdocs/library/core/class.configuration.php

532:          $TmpFile = tempnam(PATH_CONF, 'config');
533:          $Result = FALSE;
534:          if (file_put_contents($TmpFile, $FileContents) !== FALSE) {
535:             chmod($TmpFile, 0775);
536:             if (!rename($TmpFile, $File)) {
537:                // The rename may not work on Windows servers so try a copy.
538:                if (copy($TmpFile, $File)) {
539:                   unlink($TmpFile);
540:                   $Result = TRUE;

Backtrace:

/opt/bitnami/apps/vanilla/htdocs/library/core/class.configuration.phpPHP::Gdn_ErrorHandler();
[/opt/bitnami/apps/vanilla/htdocs/library/core/class.configuration.php:536] PHP::rename();
[/opt/bitnami/apps/vanilla/htdocs/library/core/functions.general.php:2146] Gdn_Configuration->Save();
[/opt/bitnami/apps/vanilla/htdocs/library/core/class.router.php:60] PHP::SaveToConfig();
[/opt/bitnami/apps/vanilla/htdocs/applications/dashboard/controllers/class.settingscontroller.php:308] Gdn_Router->SetRoute();
[/opt/bitnami/apps/vanilla/htdocs/applications/dashboard/controllers/class.settingscontroller.php:308] SettingsController->Homepage();
[/opt/bitnami/apps/vanilla/htdocs/library/core/class.dispatcher.php:322] PHP::call_user_func_array();
[/opt/bitnami/apps/vanilla/htdocs/index.php:53] Gdn_Dispatcher->Dispatch();

Yes, I will upgrade to 2.0.18.10. But, since 2.0.18.10 is only a security fix, I'd prefer to make sure to understand how to fix the issue I described before getting into any upgrade.

Thanks!

peregrine

Yes, I will upgrade to 2.0.18.10. But, since 2.0.18.10 is only a security fix, I'd prefer to make sure to understand how to fix the issue I described before getting into any upgrade.

I had to laugh here, one would thing the other way around would be the way to go.

what are the permissions on the conf folder itself

peregrine

what is your server OS and what are the permissions on conf folder. and who owns it.

and what is your php version? is 5.3.1 or above?

MaxD

@peregrine It runs on Ubuntu 12.04 on an EC2 server. For the moment the conf folder is at 775 and owned by an admin user.

peregrine

just for a test change the conf folder to 777

if it works you may need to change ownership and/or group ownership on file folder to work with 775

MaxD

@peregrine if /conf is on 777 it's working.

MaxD

yes. php version is above 5.3.1

peregrine

so solved with respect to conf. correct.

you didn't mention a problem you also might want to check the necessary permissions

uploads and
cache

chmod -R 777 the three folders.

MaxD

@peregrine Thanks a lot for your help.

x00

chmod -R 777 the three folders.

no, no!

find the process owner of the cgi scripting

<?php
$processUser = posix_getpwuid(posix_geteuid());
print $processUser['name'];

Then assign to that user. Provide write access to the folder and file that you want to be written to to that user ONLY. All else should be under another user, and with low permission for others.

I have to despair, when people have the capability to manage their server better they still don't care to learn.

chmod 777 is an unfortunate side effect of ignorance, and bad practices of cheap webhost. Really there is no excuse for using such high permissions. The use cases are precisely zero.

peregrine

I don't disagree with you x00.

Permissions should be matched with uid and gid and as tight as possible. And I am not arguing for 777. And often the forum owner is limited to the way the host provider has set there users ownership via umask etc. and what groups they belong to. etc, etc. So, if you are on a host that mungs things up. You may have to resort to less than ideal permissions.

I was just pointing out

just for a test change the conf folder to 777

if it works you may need to change ownership and/or group ownership on file folder to work with 775

but if the person is ftpping sftping ssh ing to delete ini files from cache, manually updating config.php, and removing files from fileuploads they also need permission.

also - in vanilla 2.0.18.x

just a note in vanilla it reports messages like this upon setup.:

applications/dashboard/controllers/class.setupcontroller.php:297: $PermissionHelp = '<pre>chmod -R 777 '.implode("\nchmod -R 777 ", $ProblemDirectories).'</pre>';

peregrine

@x00 said

find the process owner of the cgi scripting

yes good idea.

this has also been available in the settings of the

http://vanillaforums.org/addon/signlogger-plugin

this info as well as more ownership is In the updated

http://vanillaforums.org/addon/versioncheck-plugin-1.5