• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx

  • We are developing a new feature in Plesk that will help you promote your websites or business on social media. We want to conduct a one-hour online UX test to present the prototype and collect feedback. If you are interested in the feature, please book a meeting via this link.
    Thank you in advance!
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

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

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 ?
 
Hi @gennolo,

I think we haven't any package from Atomic:

Code:
# 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... :p
 
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?
 
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.
 
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?
 
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.
 
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 ).

 
Back
Top