Why can't I delete something even if I have 777 permissions for testing?

Question

This one is bugging me. I needed to reinstall my Joomla installation again. Which is fine since I am doing it for practice in an effort to learn Joomla and Linux (CentOSv7).

I have had previous issues with file permissions and ownership that were solved with reading error logs and testing with 777 permissions to verify running users. Problem is this time that is not working?

If everyone had permission on the images folder for example I would expect I should be able to delete anything no problem.

Here is what I get from the admin page when I try and create a folder in the root of images (with 777 perms for testing)

JFolder::create: Could not create folder. Path: /srv/dpca/www/images/test

I'm on a dedicated webhost running Nginx with PHP v5.5. Joomla does not appear to be able to write logs and the errors leads to posts about ownership and file permissions. That logically makes sense but I think I am having a different problem.

I try and delete an image with 666 permissions assigned to it and it fails and succeeds? Still does not delete though.

---

Supplement information if it helps assure my position. Root directory permissions (Note I am testing 777 on images here exclusively):

drwxr-xr-x. 10 nginx nginx  4096 Dec 24 13:51 administrator
drwxr-xr-x.  2 nginx nginx    42 Dec 24 13:51 bin
drwxr-xr-x.  2 nginx nginx     6 Jan 12 20:48 cache
drwxr-xr-x.  2 nginx nginx  4096 Dec 24 13:51 cli
drwxr-xr-x. 16 nginx nginx  4096 Dec 24 13:51 components
-r--r-----.  1 nginx nginx  1885 Jan 12 20:07 configuration.php
-rw-r--r--.  1 nginx nginx  2915 Dec 24 13:51 htaccess.txt
drwxrwxrwx.  5 nginx nginx  4096 Jan 11 21:04 images
drwxr-xr-x.  2 nginx nginx    61 Dec 24 13:51 includes
-rw-r--r--.  1 nginx nginx   140 Jan 10 22:03 index.html
-rw-r--r--.  1 nginx nginx  1212 Dec 24 13:51 index.php
-rw-r--r--.  1 nginx nginx  1873 Dec 24 13:53 joomla.xml
drwxr-xr-x.  2 nginx nginx     6 Jan 10 22:09 jrt
drwxr-xr-x.  4 nginx nginx    51 Dec 24 13:51 language
drwxr-xr-x.  5 nginx nginx    66 Dec 24 13:51 layouts
drwxr-xr-x. 11 nginx nginx  4096 Dec 24 13:51 libraries
-rw-r--r--.  1 nginx nginx 18092 Dec 24 13:51 LICENSE.txt
drwxr-xr-x.  2 nginx nginx    23 Dec 24 13:51 logs
drwxr-xr-x. 18 nginx nginx  4096 Dec 24 13:51 media
drwxr-xr-x. 27 nginx nginx  4096 Dec 24 13:51 modules
drwxr-xr-x. 14 nginx nginx  4096 Dec 24 13:51 plugins
-rw-r--r--.  1 nginx nginx  4213 Dec 24 13:51 README.txt
-rw-r--r--.  1 nginx nginx   842 Dec 24 13:51 robots.txt.dist
drwxr-xr-x.  5 nginx nginx    64 Dec 24 13:51 templates
drwxr-xr-x.  2 nginx nginx     6 Jan 12 20:52 tmp
-rw-r--r--.  1 nginx nginx  1690 Dec 24 13:51 web.config.txt

Showing that php-fpm and web server are running under correct user:

nginx     64106  0.0  1.1 412288 20668 ?        S    Jan10   0:06 php-fpm: pool www
nginx     64107  0.0  1.0 412108 20260 ?        S    Jan10   0:06 php-fpm: pool www
nginx     64108  0.0  1.2 415252 23608 ?        S    Jan10   0:06 php-fpm: pool www
nginx     64109  0.0  1.2 414472 22780 ?        S    Jan10   0:05 php-fpm: pool www
nginx     64110  0.0  1.1 413048 21340 ?        S    Jan10   0:06 php-fpm: pool www
nginx     64250  0.0  1.0 411880 20276 ?        S    Jan10   0:06 php-fpm: pool www
nginx     99912  0.0  1.1 413276 21320 ?        S    08:13   0:01 php-fpm: pool www
root     117112  0.0  0.0  47548  1184 ?        Ss   20:49   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx    117113  0.0  0.1  50144  2520 ?        S    20:49   0:00 nginx: worker process

Answer 1

The fastest way to check whether your Joomla!-installation has the necessary permission, is the built in function:

Just go to System->System Information->Folder Permissions, which should look something like this: There you can see exactly if it is a problem with your permissions, or something else.

Answer 2

SELinux was my problem. I was able to write to the directories once I set it to permissive mode.

sudo setenforce 0

However I did not want to disable it entirely as set out to correct the issue. Following the steps from CentOS on SELinux I was able to determine the correct context for the folders/files that should be writeable. While in permissive mode I added an image via the Administrator page.

By default SELinux log messages are written to /var/log/audit/audit.log via the Linux Auditing System auditd, which is started by default.

The log is a little cryptic so you can run something like this that will give a more interpretative response and even recommended action.

SELinux is preventing /usr/sbin/php-fpm from write access on the directory /srv/dpca/www/images.

*****  Plugin httpd_write_content (92.2 confidence) suggests   ***************

If you want to allow php-fpm to have write access on the images directory
Then you need to change the label on '/srv/dpca/www/images'
Do
# semanage fcontext -a -t httpd_sys_rw_content_t '/srv/dpca/www/images'
# restorecon -v '/srv/dpca/www/images'

At the time this was the context of the images (and all other folders)

drwxr-xr-x. nginx nginx unconfined_u:object_r:httpd_sys_content_t:s0 images

So I wrote a small script that read all the folders that were to be writable as per System Information > Folder Permissions (with the exception of configuration.php). It is not a good example of programming but it was basically repetition of the following commands being executed.

sudo semanage fcontext -a -t httpd_sys_rw_content_t '/srv/dpca/www/{folder}'
sudo restorecon -v '/srv/dpca/www/{folder}'

where folder was replaced for each pass. Afterwhich I set SELinux back to enforcing mode with sudo setenforce 1.

After checking System Information > Folder Permissions again I now see my folders as writable.