Plesk 12.5.30: nginx gives 403 forbidden on images after upgrade from 11.x | Page 2 | Plesk Forum
  1. Please take a little time for this simple survey! Thank you for participating!
    Dismiss Notice

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

Discussion in 'Plesk 12.x for Linux' started by rikay, Dec 15, 2015.

  1. gennolo

    gennolo Basic Pleskian

    9
    70%
    Joined:
    Nov 21, 2015
    Messages:
    49
    Likes Received:
    3
    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 ?
     
  2. Polsys

    Polsys New Pleskian

    6
    60%
    Joined:
    Aug 23, 2016
    Messages:
    11
    Likes Received:
    2
    Location:
    Barcelona
    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
     
    gennolo likes this.
  3. Peter Debik

    Peter Debik Golden Pleskian Plesk Guru

    34
    80%
    Joined:
    Oct 15, 2015
    Messages:
    1,618
    Likes Received:
    290
    Location:
    Berlin, Germany
    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?
     
  4. Polsys

    Polsys New Pleskian

    6
    60%
    Joined:
    Aug 23, 2016
    Messages:
    11
    Likes Received:
    2
    Location:
    Barcelona
    Hi @Peter Debik, thanks for commenting. Take a look at #43 where I explain a test in a server without WordPress or .htaccess
     
  5. Peter Debik

    Peter Debik Golden Pleskian Plesk Guru

    34
    80%
    Joined:
    Oct 15, 2015
    Messages:
    1,618
    Likes Received:
    290
    Location:
    Berlin, Germany
    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.
     
  6. Polsys

    Polsys New Pleskian

    6
    60%
    Joined:
    Aug 23, 2016
    Messages:
    11
    Likes Received:
    2
    Location:
    Barcelona
    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?
     
  7. gennolo

    gennolo Basic Pleskian

    9
    70%
    Joined:
    Nov 21, 2015
    Messages:
    49
    Likes Received:
    3
    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.
     
  8. Polsys

    Polsys New Pleskian

    6
    60%
    Joined:
    Aug 23, 2016
    Messages:
    11
    Likes Received:
    2
    Location:
    Barcelona
    Ouch! In my case, the problem disappears with "PHP 5.3.3 by OS vendor"
     
  9. Matric

    Matric New Pleskian

    3
    60%
    Joined:
    Jan 3, 2017
    Messages:
    1
    Likes Received:
    1
    Location:
    Toowoomba, QLD Australia
    Best Answer
    Polsys likes this.
  10. Polsys

    Polsys New Pleskian

    6
    60%
    Joined:
    Aug 23, 2016
    Messages:
    11
    Likes Received:
    2
    Location:
    Barcelona
    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 :)
     
  11. gennolo

    gennolo Basic Pleskian

    9
    70%
    Joined:
    Nov 21, 2015
    Messages:
    49
    Likes Received:
    3
    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 ).

     
Loading...