Plesk 12.5.30: nginx gives 403 forbidden on images after upgrade from 11.x

[gennolo]

Hi @Polsys,
thank you and your programmer for the efforts !

I think that this happening is similar to the previous explained behaviours (ie. regenerated thumbnails are accessible / original uploaded file returns 403).

From my side, I did some other tests by deploying some local VMs and I was able to reproduce the problem only in a
Centos 6.8 + Plesk 12.5.3 + PHP-FPM served by Nginx stack with Atomic Repository packages.
No way to reproduce the issue in Centos 7 (on the same domain).

Do you have, by chance, Atomic Repository packages ?

 

[Polsys]

Hi @gennolo,

I think we haven't any package from Atomic:

# yum -v repolist
S'està carregant el connector "fastestmirror"
Config time: 0.013
Yum Version: 3.2.29
Loading mirror speeds from cached hostfile
* base: centos.mirror.xtratelecom.es
* extras: centos.mirror.xtratelecom.es
* updates: centos.mirror.xtratelecom.es
S'estan configurant els sacs de paquets
pkgsack time: 0.036
Id-repo  : base
Nom-repo  : CentOS-6 - Base
Repo-revisió  : 1463896289
Repo-actualitzat  : Sun May 22 07:52:33 2016
Paquets-repo  : 6696
Mida-repo  : 5.5 G
Miralls-repo  : http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=os&infra=stock
URL-base-repo  : http://centos.mirror.xtratelecom.es/6.8/os/x86_64/ (9 more)
Venç-repo  : 21600 segons (últim: Fri Aug 26 12:14:32 2016)

Id-repo  : extras
Nom-repo  : CentOS-6 - Extras
Repo-revisió  : 1467739109
Repo-actualitzat  : Tue Jul  5 19:18:31 2016
Paquets-repo  : 62
Mida-repo  : 18 M
Miralls-repo  : http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=extras&infra=stock
URL-base-repo  : http://centos.mirror.xtratelecom.es/6.8/extras/x86_64/ (9 more)
Venç-repo  : 21600 segons (últim: Fri Aug 26 12:14:33 2016)

Id-repo  : plesk-php-5.6
Nom-repo  : PHP v 5.6 for Plesk - x86_64
Repo-revisió  : 1469167525
Repo-actualitzat  : Fri Jul 22 08:05:26 2016
Paquets-repo  : 31
Mida-repo  : 11 M
URL-base-repo  : http://autoinstall.plesk.com/PHP_5.6/dist-rpm-CentOS-6-x86_64/
Venç-repo  : 21600 segons (últim: Fri Aug 26 12:14:33 2016)

Id-repo  : plesk-php-7.0
Nom-repo  : PHP v 7.0 for Plesk - x86_64
Repo-revisió  : 1469165246
Repo-actualitzat  : Fri Jul 22 07:27:26 2016
Paquets-repo  : 28
Mida-repo  : 10 M
URL-base-repo  : http://autoinstall.plesk.com/PHP_7.0/dist-rpm-CentOS-6-x86_64/
Venç-repo  : 21600 segons (últim: Fri Aug 26 12:14:33 2016)

Id-repo  : updates
Nom-repo  : CentOS-6 - Updates
Repo-revisió  : 1471985397
Repo-actualitzat  : Tue Aug 23 22:53:32 2016
Paquets-repo  : 457
Mida-repo  : 2.3 G
Miralls-repo  : http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=updates&infra=stock
URL-base-repo  : http://centos.mirror.xtratelecom.es/6.8/updates/x86_64/ (9 more)
Venç-repo  : 21600 segons (últim: Fri Aug 26 12:14:33 2016)

repolist: 7274

I think I'm checking it correctly...

 

[Bitpalast]

Sounds like an .htaccess Rewrite issue, not a server issue. It is impossible that a web server makes a difference between files if these have the same permissions in the same directory, unless a rule tells it to make that difference. Do you have any plugins installed by default, e.g. a cache plugin, security plugins? Are your sure you are using an authentic, generic Wordpress installation? Test like this: Rename .htaccess from your Wordpress directory to any other name. Then try to open the file. Does the issue still occur?

 

[Polsys]

Hi @Peter Debik, thanks for commenting. Take a look at #43 where I explain a test in a server without WordPress or .htaccess

 

[Bitpalast]

If you are sure the issue is not caused by an URL rewrite, it can only be caused by false directory or file permissions. UFHH01 is right, and the error message is perfectly clear. The server cannot access the file due to missing permissions.

See https://talk.plesk.com/threads/ples...s-after-upgrade-from-11-x.336265/#post-806622

In some cases we have seen user accounts were it was necessary to move all directories and files to the psaserv group in order to let the web server access them. Try this:
chmod -R [username]: psaserv /var/www/vhosts/[subscription]/httpdocs
(had to make a space before psaserv, omit that space; As described by UFHH01, but omit the second part where you set psacln for descending directories.)

If this does not solve the issue, your cloud hosting provider has an issue in its file structure management. In that case his systems might be caching some operations or may not be displaying the real current file permissions settings. Your virtual server inside the cloud may think it has control over the file structure, but the underlying real management may have an issue with permissions, e.g. it might associate your file with a different user and therefor not deliver it to Nginx upon request. I do not think that the issue as you describe it can possibly exist on a real server.

 

[Polsys]

Finally, We think the problem is originated by PHP7 + PHP-FPM. With the combo PHP 5.3.3 + PHP-FPM all is running right.

@gennolo, are you in PHP7 too?

 

[gennolo]

Negative.

I am with plesk-php-56 package on that domain (5.6.24)
also tried with 5.4.45 (shipped by Plesk) - same problem.

 

[Polsys]

Ouch! In my case, the problem disappears with "PHP 5.3.3 by OS vendor"

 

[Matric]

Hi

I had this same issue and it was a problem with SE Linux being enabled. I was unable to browse to the original file getting a 403 from both apache and nginx. I ran the following command and could browse the file immediately.

setenforce 0

Here is the article that helped me - https://support.plesk.com/hc/en-us/articles/213947705-How-do-I-disable-SELinux-

Hope this helps someone too.

 

[Polsys]

Hi @Matric, thanks for your post: with SELinux disabled this problem disappears. Maybe @UFHH01 or @Peter Debik can help us a little more after this information

 

[gennolo]

Hello,
I am returning on this topic because I think a definitive solution had not been found yet.

We found the culprit (SeLinux) but I don't think that disabling it at all is a good idea.

Note that after some further investigation I figured out that the "forbidden" resources are moved
from /var/lib/php/session to the vhost destination folder.

I think the problem identified in the topic is generated for this reason by the various editors
(wordpress etc.) that use the PHP session to upload files.

If I launch : chcon -t httpd_sys_rw_content_t ./*

to change che file context on the vhost folder I see that the resource is not forbidden anymore,
however trying to changing the same context also on the /var/lib/php/session folder does not seem to help,
because after uploading a new files I get 403 forbidden again (I found some useful info on this article ).