Por que não consigo excluir algo, mesmo que possua permissões 777 para teste?
Este aqui está me incomodando. Eu precisava reinstalar minha instalação do Joomla novamente . O que é bom, já que estou fazendo isso para praticar, em um esforço para aprender Joomla e Linux (CentOSv7).
Eu tive problemas anteriores com permissões de arquivo e propriedade que foram resolvidos com a leitura de logs de erros e testes com permissões 777 para verificar os usuários em execução. Problema é desta vez que não está funcionando?
Se todos tivessem permissão na pasta de imagens, por exemplo, eu esperaria poder excluir qualquer coisa sem problemas.
Aqui está o que recebo da página de administração quando tento criar uma pasta na raiz das imagens (com 777 permissões para teste)
JFolder::create: Could not create folder. Path: /srv/dpca/www/images/test
Estou em um host dedicado executando o Nginx com PHP v5.5. O Joomla não parece capaz de gravar logs e os erros levam a postagens sobre propriedade e permissões de arquivo. Isso faz sentido logicamente) mas acho que estou tendo um problema diferente.
Tento excluir uma imagem com 666 permissões atribuídas e ela falha e é bem-sucedida? Ainda não exclui embora.
Complemente as informações se isso ajudar a garantir minha posição Permissões do diretório raiz (note que estou testando 777 exclusivamente em imagens aqui):
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
Mostrando que o php-fpm e o servidor da web estão sendo executados com o usuário correto:
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
O SELinux era meu problema. Consegui gravar nos diretórios depois de configurá-lo para o modo permissivo.
Sudo setenforce 0
No entanto, eu não queria desabilitá-lo totalmente, conforme definido para corrigir o problema. Seguindo as etapas de CentOS no SELinux Consegui determinar o contexto correto para as pastas/arquivos que deveriam ser graváveis. Enquanto estava no modo permissivo, adicionei uma imagem na página Administrador.
Por padrão, as mensagens de log do SELinux são gravadas em /var/log/audit/audit.log através do Linux Auditing System auditd, que é iniciado por padrão.
O log é um pouco enigmático, portanto, você pode executar algo assim que fornecerá uma resposta mais interpretativa e até a ação recomendada.
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'
Naquele momento, esse era o contexto das imagens (e de todas as outras pastas)
drwxr-xr-x. nginx nginx unconfined_u:object_r:httpd_sys_content_t:s0 images
Então, escrevi um pequeno script que lia todas as pastas que deveriam ser gravadas conforme Informações do sistema> Permissões de pasta (com exceção do configuration.php). Não é um bom exemplo de programação, mas foi basicamente a repetição dos seguintes comandos sendo executados.
Sudo semanage fcontext -a -t httpd_sys_rw_content_t '/srv/dpca/www/{folder}'
Sudo restorecon -v '/srv/dpca/www/{folder}'
onde a pasta foi substituída para cada passe. Após o que eu configurei o SELinux de volta ao modo de imposição com Sudo setenforce 1.
Depois de verificar Informações do sistema> Permissões de pasta novamente, agora vejo minhas pastas como graváveis.
A maneira mais rápida de verificar se a sua instalação do Joomla! Tem a permissão necessária, é a função integrada:
Vá para Sistema-> Informações do sistema-> Permissões de pasta, que devem ser algo como isto: 
Lá você pode ver exatamente se há algum problema com suas permissões ou outra coisa.