chmod(): Operation not permitted - which user should be moodledata owner?

chmod(): Operation not permitted - which user should be moodledata owner?

by Mathew Gancarz -
Number of replies: 6
Picture of Core developers

Hi all, I've been seeing these messages popping up for me occasionally and I think I've tracked down the cause. The full error is:

PHP Warning:  chmod(): Operation not permitted in /var/....../lib/filestorage/file_storage.php on line 2194, referer: http://........./course/delete.php?id=103

Looking at the code, that line performs a chmod on trash files: https://github.com/moodle/moodle/blob/master/lib/filestorage/file_storage.php#L2194

Our Moodledata directory is set to root:apache permissions with  0660 on the files. But even though the apache user is allowed to write the files, because it is not the owner, it's not allowed to chmod the files.

I'm thinking now the proper ownership on the moodledata directory be apache:apache, What are people's thoughts?


Average of ratings: -
In reply to Mathew Gancarz

Re: chmod(): Operation not permitted - which user should be moodledata owner?

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

If that's the apache owner on your server then, yes, it's apache:apache. If the machine isn't shared you could just chmod -R 0777 your moodledata.

In reply to Mathew Gancarz

Re: chmod(): Operation not permitted - which user should be moodledata owner?

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators
Hello Mathew

You wrote:
> Our Moodledata directory is set to root:apache permissions with 0660 on the files.

It should be possible to have root as the owner of the moodledata directory, provided that you give the apache-user full write permissions in moodledata. What does ls -ld /path/to/moodledata show? In your case it should print something like drwxrwxXXX root apache-group (X means don't care).

> But even though the apache user is allowed to write the files, because it is not the owner, it's not allowed to chmod the files.

A bit of a confusion there - your apache-user and apache-group both are called apache!

Anyway, could the problem a) missing x in moodledata, I mean drwxrw-XXX instead of drwxrwxXXX? Or, $CFG->directorypermissions not right?
In reply to Visvanath Ratnaweera

Re: chmod(): Operation not permitted - which user should be moodledata owner?

by Mathew Gancarz -
Picture of Core developers

Hi Visvanath, 

Good note about differentianting between apache-user and apache-group.

We've been running with it set to root:apache-group for a number of years, the moodledata folder itself has permissions drwxrws--- 

Config.php has $CFG->directorypermissions = 02770;

I just did test though, and on my system, CentOS 7, group write permissions on a file do not let you chmod it. An account can only chmod a file/folder that it is the owner of. 

This would explain all the historical reports of chmod() operation not permitted, because unless the actual apache/web server user is the owner of the files in the moodledata folder, it will not be allowed to run chmod on the files and the errors will be generated.

In reply to Mathew Gancarz

Re: chmod(): Operation not permitted - which user should be moodledata owner?

by Mathew Gancarz -
Picture of Core developers

And actually looking at the recommendations for file system permissions in the docs: https://docs.moodle.org/31/en/Security_recommendations#Most_secure.2Fparanoid_file_permissions

It does state it should be owned by apache-user and group set to apache-group. Looks like I've been running it incorrectly for a while. Atleast now I know! smile

1. moodledata directory and all of its contents (and subdirectories, includes sessions):

owner: apache user (apache, httpd, www-data, whatever; see above)
group: apache group (apache, httpd, www-data, whatever; see above)
permissions: 700 on directories, 600 on files

2. moodle directory and all of its contents and subdirectories (including config.php):

owner: root
group: root
permissions: 755 on directories, 644 on files.

If you allow local logins for regular users, then 2. should be:

owner: root
group: apache group (apache, httpd, www-data, whatever; see above)
permissions: 750 on directories, 640 on files.

In reply to Mathew Gancarz

Re: chmod(): Operation not permitted - which user should be moodledata owner?

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators
Hi Mathew

You wrote:
> It does state it should be owned by apache-user and group set to apache-group. Looks like I've been running it incorrectly for a while.

In my opinion Moodle does allow a number of combinations for the owner, group and permissions of the moodledata directory and its contents. (Let us limit the discussion to moodledata/, leave moodle/ out.) In fact I have Moodle instances running where the owner of moodledata/ is not the apache-user.

> group write permissions on a file do not let you chmod it. An account can only chmod a file/folder that it is the owner of.

You are right. But I have never encountered this as a problem. Is it an error or just a warning? Do you have any idea why Moodle needs to change the permissions of files/directories within moodledata/ _after_ they have been created?
In reply to Visvanath Ratnaweera

Re: chmod(): Operation not permitted - which user should be moodledata owner?

by Mathew Gancarz -
Picture of Core developers

Is it an error or just a warning? Do you have any idea why Moodle needs to change the permissions of files/directories within moodledata/ _after_ they have been created?

It states PHP Warning, and it looks to be in the "deleted_file_cleanup" function. You can see the code here: https://github.com/moodle/moodle/blob/master/lib/filestorage/file_storage.php#L2194

I'm not quite sure why that piece of code changes permissions on file it's deleting, but it's been there since before 2010 and that's as far back as I can go in the Github history. Seems to have been in place for Moodle 2.0, not sure if earlier.