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

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
    Commented May 7, 2014 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 Commented May 7, 2014 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
    Commented May 7, 2014 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 Commented May 7, 2014 at 17:13
  • I'll write it as an answer.
    – JMC
    Commented May 7, 2014 at 17:16

2 Answers 2


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

setenforce 0

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.

  • Unfortunately, I don't have any SMB access to the server that is hosting the Moodle. Any other ideas? Commented May 7, 2014 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
    Commented May 7, 2014 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 Commented May 7, 2014 at 19:44
  • You can put this in there also to make sure you see them all: error_reporting(-1);
    – JMC
    Commented May 7, 2014 at 19:50
  • +1 for "moving the production site to a test server", +1 for error logging and reporting. Commented May 9, 2014 at 16:39

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