First, put all your web content data under
/var/www/html/. However, Fedora does not allow Apache to write anything anywhere by default, unless you explicitly permit that.
For that, proper file/directory permissions are required, but not enough.
Fedora uses SELinux (Security Enhanced Linux) to provide more robust security, and it doesn’t allow Apache to write anything by default too.
Now, for each file and/or directory which should be writable (for which you receive
... is not writable errors) you should set
unconfined_u:object_r:httpd_sys_rw_content_t:s0 SELinux label to tell SELinux that these files/directories are allowed to be modified by Apache. For example, to make
/var/www/html/moodle/theme writable, you should run (you can use
-R so that this lable is set recursively if these directories contain subdirectories which should be writable):
chcon -R unconfined_u:object_r:httpd_sys_rw_content_t:s0 /var/www/html/whatever
Now, you can run
setenforce 1 and see if the webiste is working properly. This is the solution.
But, what about
setenforce 0 command? This command changes SELinux mode into
permissive mode. In this mode, SELinux doesn’t prevent any activity and only generates error messages in system’s audit logs. This is why you didn’t receive error messages anymore. However, putting SELinux in permissive mode is NOT a proper solution to make things work, I used it to see if your problem is related to SELinux. And,
setenforce changes SELinux mode temporarily (until next shutdown/reboot).
setenforce 1 changes the SELinux mode to the default one, which is
enforcing mode in which SELinux does actually prevent un-allowed activities.
This is the workflow that I would suggest when setting up a new thing in Fedora:
- Put SELinux into Permissive mode (
- Set up the system as you like and make sure that it works correctly as intended
- Put SELinux back to Enforcing mode (
- See if your system is still working fine. If not, check for SELinux errors in system audit logs (
/var/log/audit) and try to solve the errors appropriately (it usually involves changing file/directory SELinux lables, or changing SELinux boolean parameters). A more user friendly approach is to use
SELinux TroubleshooterGUI application rather than inspecting audit logs. It shows SELinux related errors along with suggested solutions.
Notice that you can modify SELinux configuration file (
/etc/selinux/config) to completely disable SELinux or permanently set it into Permissive mode, but please don’t. While many will suggest it as a solution to SELinux related problems, it is more like removing the problem rather than a solution for itu. However, for a development system where security is not important, you might decide to do that (In that case, I would personally prefer using permissive mode rather than completely disabling SELinux, so that you can still know about SELinux permission erros). When you decided to deploy your web application to production servers, you should know how to properly configure SELinux so that your web application works correctly even when SELinux is in Enfrocing mode.