3

I am running a Moodle 2.4.8 (Build: 20140113) on a Debian Squeeze box, with Apache 2.2. Whenever a user (even the admin user) makes changes to certain settings (i.e. adding a user), or just accessing certain courses (in this case, Math 9), the page pops up with a 503 error, Fatal error: $CFG->dataroot is not writable, admin has to fix directory permissions! Exiting.

Checking my /config.php file, I see the path is set to /var/moodledata2, which is owned by www-data www-data, and permissions are lined up with the Moodle documentation.

This was intermittent at the start of the week, but now it's getting to be constant. There is lots of free space available (as shown below):

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/md2               83G   37G   42G  48% /
tmpfs                 2.0G     0  2.0G   0% /lib/init/rw
udev                  2.0G  224K  2.0G   1% /dev
tmpfs                 2.0G     0  2.0G   0% /dev/shm
/dev/md1              939M   35M  857M   4% /boot
/dev/md3              822G  355G  426G  46% /var
/dev/md4              917G   72G  799G   9% /var/moodledata2

# cat config.php
<?php  // Moodle configuration file

unset($CFG);
global $CFG;
$CFG = new stdClass();

$CFG->dbtype    = 'mysqli';
$CFG->dblibrary = 'native';
$CFG->dbhost    = 'localhost';
$CFG->dbname    = 'moodle2';
$CFG->dbuser    = 'root';
$CFG->dbpass    = '<removed>';
$CFG->prefix    = 'mdl_';
$CFG->dboptions = array (
  'dbpersist' => 0,
  'dbsocket' => 0,
);

$CFG->wwwroot   = 'http://example.com/moodle2'; // <removed>
$CFG->dataroot  = '/var/moodledata2';
$CFG->admin     = 'admin';

$CFG->directorypermissions = 0777;

$CFG->passwordsaltmain = '<removed>';

require_once(dirname(__FILE__) . '/lib/setup.php');

// There is no php closing tag in this file,
// it is intentional because it prevents trailing whitespace problems!
#

I'm at a loss for what to do. Permissions seem logical in how they should be (www-data owning everything, and having full access to the /var/moodledata2 folder). What is my next step?

  • Have you checked the permissions of the individual php files on the server? I see you mentioned proper ownership by www-data but something could be wrong on certain files that need write permission. Or some processes that create new files in moodledata2 are not set at correct permissions. – JMC May 7 '14 at 17:09
  • @JMC Are you talking about inside the /var/moodledata2 directory? I did a chmod -R 777 /var/moodledata2, so that should have got everything. I'll doublecheck though. Looks correct to me, in all the subfolders – Canadian Luke May 7 '14 at 17:10
  • Ya you would think that would be enough, it seems that you need to trace individual processes that are failing to the files they interact with and look at those files individually for problems. For example I've used some programs that create new log files at 777 even though I changed all existing log files to 600 after the fact. – JMC May 7 '14 at 17:12
  • @JMC Can I get info on how to find out how to do that? Or can you tell me how to do that directly? Lol – Canadian Luke May 7 '14 at 17:13
  • I'll write it as an answer. – JMC May 7 '14 at 17:16
2

Edit: Forgot to mention one of the obvious techniques. Read the server and program error logs for more information on specific problems. Errors displayed to the user through the frontend are often made intentionally generic.

To the solve the problem, find the files that are used in the failing processes by debugging the program (or ask the developers directly, might be the easiest route). One efficient way to debug a php program is to load it into a program like phpeclipse. Once you know the files causing the issue, check them individually for problems. You could be running into a corruption problem or an issue where files are not created by the program with correct ownership or permissions.

This link may help you get started on debugging: http://www.ibm.com/developerworks/library/os-debug/

Also make sure that the new files created in the data directory have the correct permissions and ownership. Sometimes a script is unable to create new data on the server because the running script doesn't have proper permissions to create new data because the data directory is too restrictive.

This would be my step 1: If none of the above works or seems too daunting, try moving the production site to a test server and see if you can replicate the problem. Even better if you can move it to a different operating system structure to help isolate server config vs program problems.

| improve this answer | |
  • Unfortunately, I don't have any SMB access to the server that is hosting the Moodle. Any other ideas? – Canadian Luke May 7 '14 at 19:28
  • @Canadian Luke - inserting ini_set('display_errors', '1'); at the top of index.php will let you see the real errors but this being production could cause you security issues and usability problems. – JMC May 7 '14 at 19:41
  • It seems to be running right now, but I put that in just in case. If it prints something out, I have 3 staff members who will see it, and let me know. I'll check back tomorrow – Canadian Luke May 7 '14 at 19:44
  • You can put this in there also to make sure you see them all: error_reporting(-1); – JMC May 7 '14 at 19:50
  • +1 for "moving the production site to a test server", +1 for error logging and reporting. – That Brazilian Guy May 9 '14 at 16:39
2

I got the same error in Centos 7, after this linux command ,It's working fine!

setenforce 0
| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.