suphp breaking WP sites
Hello
I need help with some permissions problem.
I have several WP sites working normally on ea4-5.6 Cloudlinux and suPHP
I have a couple of older sites that were transferred from another server and they require php5.5 and they work fine on this, except for when I need to install WP updates etc in the admin backend I get the annoying:
"To perform the requested action, WordPress needs to access to your web server. Please enter your FTP credentials to proceed. If you do not remember your credentials, you should contact your web host."
I have checked phpconf and I can see that suPHP is not enabled on the 5.5
However when I enable suphp on the 5.5 the sites return the "500 Internal Server Error". I get the same result if I change php to version 5.6. In the error logs I see these:
In cPanel for the user, all file / folder permission appear to be correct 755. There are no residual rules in .htaccess from previous server and there is no custom php.ini file. So I believe this is a "owner" permissions error but I am not really sure how to fix and would like advice. Thank you
[root~]# /usr/local/cpanel/bin/rebuild_phpconf --current
DEFAULT PHP: ea-php56
ea-php55 SAPI: cgi
ea-php56 SAPI: suphp
ea-php70 SAPI: cgi
However when I enable suphp on the 5.5 the sites return the "500 Internal Server Error". I get the same result if I change php to version 5.6. In the error logs I see these:
End of script output before headers:
SoftException in Application.cpp:362: GID of script "/home/user/public_html/index.php" is smaller than min_gid
In cPanel for the user, all file / folder permission appear to be correct 755. There are no residual rules in .htaccess from previous server and there is no custom php.ini file. So I believe this is a "owner" permissions error but I am not really sure how to fix and would like advice. Thank you
-
run chown -R user:user /home/user/public_html chown user:nobody /home/user/public_html for the affected accounts of course changing the user to the real user 0 -
Well after spending a few hours Workin On It - Of course, I had simply to chmod the user directory.... I had done that already, but of course then I upgraded to EA4 and that had wiped out the permissions! Problem solved! 0 -
New Well after spending a few hours Workin On It - Of course, I had simply to chmod the user directory.... I had done that already, but of course then I upgraded to EA4 and that had wiped out the permissions!
Hello, I'm happy to see the issue is now resolved. Could you verify which directory you had to change permissions on, and what you changed the permissions from, and to? Thank you.0 -
This is one of those warning I always think of when I see someone suggesting chmod and chown users files. Cpanel Easyapache Symlink w/dso vs suPHP 0 -
Here's a very, very basic script that will fix almost every suphp permission/uid issue. Been using it for years, I just forget where I grabbed it from :) #! /bin/bash verbose="" #Print the help text helptext () { tput bold tput setaf 2 echo "Fix perms script help:" echo "Sets file/directory permissions to match suPHP and FastCGI schemes" echo "USAGE: fixperms [options] -a account_name" echo "-------" echo "Options:" echo "-h or --help: print this screen and exit" echo "-v: verbose output" echo "-all: run on all cPanel accounts" echo "--account or -a: specify a cPanel account" tput sgr0 exit 0 } # Main workhorse, fix perms per account passed to it fixperms () { #Get account from what is passed to the function account=$1 #Check account against cPanel users file if ! grep $account /var/cpanel/users/* then tput bold tput setaf 1 echo "Invalid cPanel account" tput sgr0 exit 0 fi #Make sure account isn't blank if [ -z $account ] then tput bold tput setaf 1 echo "Need an account name!" tput sgr0 helptext #Else, start doing work else tput bold tput setaf 4 echo "Fixing perms for $account:" tput setaf 3 echo "------------------------" tput setaf 4 echo "Fixing website files...." tput sgr0 #Fix individual files in public_html find /home/$account/public_html -type d -exec chmod $verbose 755 {} \; find /home/$account/public_html -type f | xargs -d$'\n' -r chmod $verbose 644 find /home/$account/public_html -name '*.cgi' -o -name '*.pl' | xargs -r chmod $verbose 755 chown $verbose -R $account:$account /home/$account/public_html/* find /home/$account/* -name .htaccess -exec chown $verbose $account.$account {} \; tput bold tput setaf 4 echo "Fixing public_html...." tput sgr0 #Fix perms of public_html itself chown $verbose $account:nobody /home/$account/public_html chmod $verbose 750 /home/$account/public_html #Fix subdomains that lie outside of public_html tput setaf 3 tput bold echo "------------------------" tput setaf 4 echo "Fixing any domains with a document root outside of public_html...." for SUBDOMAIN in $(grep -i document /var/cpanel/userdata/$account/* | awk '{print $2}' | grep home | grep -v public_html) do tput bold tput setaf 4 echo "Fixing sub/addon domain document root $SUBDOMAIN...." tput sgr0 find $SUBDOMAIN -type d -exec chmod $verbose 755 {} \; find $SUBDOMAIN -type f | xargs -d$'\n' -r chmod $verbose 644 find $SUBDOMAIN -name '*.cgi' -o -name '*.pl' | xargs -r chmod $verbose 755 chown $verbose -R $account:$account $SUBDOMAIN find $SUBDOMAIN -name .htaccess -exec chown $verbose $account.$account {} \; done #Finished tput bold tput setaf 3 echo "Finished!" echo "------------------------" printf "\n\n" tput sgr0 fi return 0 } #Parses all users through cPanel's users file all () { cd /var/cpanel/users for user in * do fixperms $user done } #Main function, switches options passed to it case "$1" in -h) helptext ;; --help) helptext ;; -v) verbose="-v" case "$2" in -all) all ;; --account) fixperms "$3" ;; -a) fixperms "$3" ;; *) tput bold tput setaf 1 echo "Invalid Option!" helptext ;; esac ;; -all) all ;; --account) fixperms "$2" ;; -a) fixperms "$2" ;; *) tput bold tput setaf 1 echo "Invalid Option!" helptext ;; esac
To use -- login via ssh -- save everything in the code block as a file (I call it fixperms) -- chmod the file (chmod a+x fixperms) -- run the file. Initially, I'd run it as ./fixperms -all . You can run it as ./fixperms -a [username] as well Ignore errors that it spits out. I've yet to see what's causing those, or a fix to them, but it's harmless You can also run this on a periodic basis (say, maybe monthly) to automatically fix user permission issues for them, if you're feeling adventurous0 -
Appears to be from here: gist.github.com/webspectyler/6900878 0
Please sign in to leave a comment.
Comments
6 comments