Common Moodle LMS installation mistake #3: Incorrect file or directory permissions

Moodle LMS is an advanced, feature-rich Learning Management System (LMS) that can operate reliably and performs well with sufficient CPU and memory right out of the box. When incorrectly installed, it can lead to a frustrating experience and misplaced blame on Moodle. This article deals with the third most common installation error, incorrect file and directory permissions of your Moodle application and moodledata files and folders.

Moodle needs to be able to create, read, write and delete files on your web server. I can’t begin to list the myriad of things that can go wrong if your web server has insufficient file and directory permissions. This is a common installation mistake, especially if you installed Moodle from the command line.

Server administrators sometimes set the Moodle application file area to be read-only for security reasons. For example, this might be to prevent the installation of themes and plugins in a managed Moodle LMS hosting environment (e.g. MoodleCloud), or you are running Moodle LMS in a virtual containerized environment (e.g. Docker). This is quite common and these are perfectly valid reasons for doing this. However, if this was not the intention, your website just isn’t showing any indications of life, or you want to but cannot install plugins from inside Moodle, your web server likely has a file and directory permissions issue.

Moodle LMS also needs to have full access to the moodledata folder. It uses this workspace for multiple purposes such as storing course files, caching files, storing additional/custom language strings and more. Moodle LMS must therefore have full control of that space.

How Moodle LMS Owner, Group and Permissions issues happen

File and directory permissions can be confusing to new server administrators until they realize that the web server service is often running under a different user than they are.

For example, this type of issue can happen when you perform the following from a command line terminal or using an SSH application like WinSCP:

• Installing Moodle;
• Cloning a Moodle server;
• Restoring a backup of a Moodle site;
• Updating or upgrading Moodle;
• Manually installing plugins and themes;
• Running commands as sudo or su (superuser);
• Running cron under the wrong user account; or
• Editing files like Moodle's config.php.

How to Fix Owner, Group and Permissions for Moodle LMS

Resolving this issue varies considerably from one server to another. You will need to:

1. Determine your operating system. For example: Windows, MacOS, Ubuntu, Debian, openSUSE, SLES, CentOS, Fedora and Red Hat)
2. Determine which web server software you are running. For example, iis, nginx, apache, apache2 or httpd - but it could be something else.
3. Identify under which user your web server is running. For example www-data, root, apache or uid 1005 - but it could be something else.
4. Determine to which groups the web server user belongs to. For example, www-data, root, apache or group gid 1005 - but it could be something else.
5. Use the "chown" command to set the group for each of the files and folders to a group to which the web server user belongs.

For example, this often works on Ubuntu and Debian servers running Apache:

# Access your web server using a terminal.
# Change into the webroot of your Moodle LMS.
# Set permissions of all the directories.
sudo find . -type d -exec chmod 2770 {} \;
# Sert permissions of all the files.
sudo find . -type f -exec chmod 0660 {} \;
# Set the owner and the group for all files and directories.
sudo chown -R $USER:www-data .
# Repeat these commands in the moodledata directory.

What do these commands do?

The "sudo find" command is used to switch to the superuser on the server so that it can then find files or directories and set specific permissions for files and folders.

The position of each of the 4 digits has a special meaning. Starting from the left, the 2 causes files and subdirectories created within to inherit its group ownership. Unless the file is an executable (PHP scripts are not executables), this digit's position has no effect so we set it to 0 for files. If omitted, 0 is the default.

The second, third and fourth digits tell Linux what permissions the owner, group and other users can do with the file or directory. These numbers represent the sum of the permission values and carry a different meaning depending on whether they are applied to directories or files.

For directories

For directories, the chmod command does the following:

• 4: Read permission means you can list the contents of that directory.
• 2: Write permission means you can add or remove files in that directory.
• 1: Execute permission means you can list information about the files in that directory.

These numbers are added up to determine the combined permissions. For example, a 7 means that the directory can be listed, files can be added and removed and you can list information about the files.

We therefore set the Owner, Group permissions of all files to 7 (4+2+1). Since only you and the web server need to access the files, access for Others is set to 0 (no access).

For Files

For files, the chmod command does the following:

• 4: Read permission, the user or group can read the file.
• 2: Write permission, the user or group can write and update the file.
• 1: Execute permission, the user or group can run the executable file. Since PHP files are not executable but interpreted, this is never needed for Moodle files.

We therefore set the Owner, Group permissions of all files to 6 (4+2). Since only you and the web server need to access the files, access for Others is set to 0 (no access).

Last, the chown command sets owner and group of all files and folders (owner:group).

The commands would be similar on most Unix, Linux distros and MacOS servers but the 2770, 0660 and www-data could likely be different. Needless to say, Windows works very differently and will need different instructions depending on if the servers are running as a service or as an application.

Occasionally, I find that the user account running the web server was not configured to be part of the expected group. The best fix is to add that user to the expected group for security reasons. However, you could also fix the problem by granting "other" access by changing the 2770 to 2777 and 0660 to 0666. This is a security issue if there are non-admin users with access to the web server. If you don't want your Moodle site administrator to be able to add, remove or update plugins, change these 2770 to 2760 or 2766, and the 0660 to 0650 or 0655 for the Moodle application only.

The key is to ensure that the user or group under which your web server (e.g., Apache, nginX) is running has the appropriate permissions to read files. In the case of moodledata, it also needs to be able to create, write and delete files and directories.

Avoid running into owner, group and permission issues on your Moodle LMS site

You can avoid running into permission issues by first ensuring that owner, group and permissions are correctly configured for all files and directories related to your Moodle LMS. Then:

1. Run commands that make changes to files and directories, including Git, using the same user under which the web server is running - assuming the user account running the web server has sufficient permissions.
2. Run cron as the same user as the web server.
3. Install and update plugins and themes from inside Moodle. This will result in the operations being carried out as the same user running the web server.
4. Create a little (bash) script that resets the owner, group and permissions of all Moodle LMS application and data files and get into the habit of running it after any manual manipulation of files and directories.

For more information, see Understanding Linux File Permissions, the documentation for your specific operating system and the Security Recommendations for Moodle LMS.

Hope you found this information helpful.

Michael Milette