Permission problem in WP

Discussion in 'Linux VPS/Dedicated - cPanel' started by szury, May 21, 2010.

  1. szury

    szury New Member

    I have recently moved to knownhost.

    My problem is that whenever I want to change something in WP admin (css, header.php or permalinks) I get an error saying that my htaccess is not writable.

    Mu htaccess file is set to permissions 644. If I set it to 777 it works fine but wordpress recommends to leave it in 644 and it worked fine with 644 on my old host.

    I contacted the support and they said it won't work in 644 and that I had to change it whenever I want to update these files.

    How did you get around this? Is it safe to leave the file in 666 (i think it also works with 666).???
     
  2. khiltd

    khiltd New Member

    What's WP?
     
  3. Bryan

    Bryan Very Happy KH VPS User

    WordPress I would assume.
     
  4. khiltd

    khiltd New Member

    Then you might need to rebuild with suPHP support enabled if it isn't already.
     
  5. szury

    szury New Member

    Yes it's Wordpress of course :).
    Is there a way in php? I don't want to switch to suphp.
     
  6. Dan

    Dan Moderator

    Hello Szury,

    Have you looked at the WP forums? Odds are you will find much more information there.

    Oh and by the way if you were running 644 on your previous host then you were running on suPHP.
     
  7. szury

    szury New Member

    I will try that thanks. :)
     
  8. echizen

    echizen New Member

    Hi all KH'ers, I am new here and really newbie, I also got some problem happen to szury.

    what is suphp and how to solve this problem using suphp?

    thanks and sorry for my poor english.
     
  9. szury

    szury New Member

    hey echizen.
    I didn't solve the problem. I am uploading my files via FTP.

    The only solution is suphp but that is 20-30% slower than normal php so I'll just leave everything as it is. Hope it helps.
     
  10. Dan

    Dan Moderator

    Hey guys!

    To enable suPHP assuming it is built in already. If it is not Apache/PHP will need to be recompiled.

    In WHM go to Service Configuration | Apache Configuration | PHP and SuExec Configuration

    Then make sure the default PHP version is set to 5 and for the PHP handler select suPHP and set Apache suEXEC to On.

    Save the new configuration and you should be good to go!

    Szury, I would not agree that suPHP reduces performance THAT much I know it didn't on my system. Perhaps the numbers you are looking at are in reference to a lesser system.
     
  11. echizen

    echizen New Member

    Hi szury, I am not sure to enabling suPHP, now I am doing this: changing permission (chmod) to 755 (for directories), 644 (for files) and 666 (for .htaccess and files under themes and plugins directory). I am not sure with the security issues but I found this link www[dot]tamba2[dot]org[dot]uk/wordpress/chmod/ hope its useful.

    :cheer:
     
  12. szury

    szury New Member

    Thanks both for your reply. I will leave it like this at the moment.
     
  13. newe1344

    newe1344 New Member

    Permission Problem

    Hi:

    Had this problem before, it happened to me on both wordpress and joomla. Basically your files (when installed with cpanel) are set to a certain permission, and cpanel sets the owner and group owner to your user account. Then when php executes with apache (which is the same as the user "nobody") it doesn't have permission to write to those files.

    I was having trouble with uploads so I simply set my uploads directory to:
    Code:
    chown -R userAccount:nobody /home/userAccount/public_html/wp-content/uploads
    
    Just replace "userAccount" with the correct user for that account...

    Then I gave the "uploads directory" permissions:
    Code:
    chmod 775 /home/userAccount/public_html/wp-content/uploads
    
    You might want to try and make it chmod 755 first, and if that doesn't work, switch it to chmod 775. You should review permission on linux systems first and make sure you are aware of the risks. In my situation, I am willing to deal with the risk for the added convenience, however, if you are using your VPS as a production server with multiple users this may not be the right course of action.

    Knownhost support is correct, the safest way to handle this would be to change the permissions only when you want to change something. This would prevent scripts from having write access when you are not aware.

    If anyone disagrees with me or I am incorrect, please respond. I want to learn from these forums so if anyone has something to teach, please share it with us!:)
     
  14. Dan

    Dan Moderator

    To expand on what Newe1344 is saying. When you set permissions to 775 you are giving the group (which is nobody or Apache as set above) full read/write/execute access to this folder. This is never a good idea and, very worst case scenario, can result in your VPS being hacked.
     
  15. newe1344

    newe1344 New Member

    How to set it up properrly?

    Hi Dan:

    Could you clarify? I am under the impression that if you are the sole user of your VPS that world permissions are not accessible from anyone over the internet, just anyone logged into your server. Correct?

    Also, how would you advise setting up apache so it you can have directory perms of 755 and file perms of 644? When I moved over from godaddy that was the standard for most directories and files. I feel this is much safer but I am not sure how they set up user:group permissions in order to achieve this.

    Thanks for your help on this!

    @Everyone: Beware of my post above, I am using my VPS to experiment, the advice I gave was not intended for a production environment. I am still learning, so please don't follow my advice if you aren't aware of the risks involved in setting up your file permissions this way.:)
     
  16. khiltd

    khiltd New Member

    No. If someone decides to exploit a security flaw in Apache while Apache has write privileges to all of your files then you can kiss everything goodbye. The fact that it typically runs as "nobody" is not an accident.
     

Share This Page