Could not create directory. /public_html wordpress

Just upgraded to wordpress 3.0, and here come the bugs:

When you’re trying to upgrade the plugins, you might get this error over and over again:
Could not create directory. /public_html wordpress
Solution: go to wp-content -> upgrades folder,  remove it, and then recreate it and chmod 777.

This should fix the problem easily enough.

14 Responses to “Could not create directory. /public_html wordpress”

  1. Jim says:

    It actually worked – Thanks for posting this!

  2. RJ Howard says:

    I am astonished that this worked. Just changing the perms is not enough (why?). You have to delete the directory, recreate it, and change the perms.

  3. moeed says:

    but how can i recreate a new upgrade folder

  4. Rod says:

    I’ve used this method several times and it has always worked. Don’t know why, perhaps something in the old upgrade folder gets corrupted or something left behind that should have been cleaned up afterward.

    @moeed Just use you ftp program or cPanel file manager (if you have it) to create a new folder named “upgrade” in the wp-content directory then set permissions to 777
    Make sure to name it “upgrade” not “upgrades” as I’ve seen suggested on a few other forums.

  5. Doru says:

    Te poti considera un privilegiat al soartei, in cazul meu acest update a reusit sa imi “stirbeasca” destule functii din template.
    Doru´s last blog post ..Google PacMan

  6. mark says:

    not working on me T_T

  7. ervis says:

    how to chmod 777? I don’t know what this means

  8. This worked for me. Many Thanks!

    (To CHMOD to 777, you need to change the permissions of a folder in your FTP client. Change the number from what ever is listed to 777.)

  9. Vishnu says:

    Not working for me 🙁 was trying to upgrade from 3.0 to 3.0.1

    Downloading update from http://wordpress.org/wordpress-3.0.1.zip…

    Unpacking the update…

    Could not create directory.: /public_html

    Installation Failed

  10. It worked for me, too. I also noticed some other strange behavior in this arena.
    I found many plugins could be upgraded automatically. Others failed, and when they failed, they left a directory in the upgrades directory, and when that left over directory was present, no other automatic updates would work.

    I also noticed that upgrades to the overall version of WordPress usually failed, so I would end up having to do it manually. But, during the times with the upgrades did work, it would still leave the latest wordpress update in the upgrade directory without removing it, so other plugin and theme updates would fail predictably.

    I tried setting perms to 777 initially but found it didn’t seem to help. However, this was all on a C-panel setup, so my ability to see ownership of the directories and files was limited. It seemed I was operating with one userid when logged into C-panel, another when logged into C-panel as the reseller, another when PHP code was running under apache or whatever webserver they were using–I’m almost certain it’s apache.

    But, the strange thing is deleting and recreating this directory would seem to create it to be owned by whoever I am Unix-wise, while logged into C-panel. Yet, perms of 777 would seem to open things up to everyone. There did not seem to be a 1 in front of the 777 either before or after.

    Well, I’ll probably figure out why this method worked in the middle of the night when I’m supposed to be sleeping and feel stupid for not seeing it sooner. But, that’s life 🙂

  11. What’s up Dear, are you truly visiting this web site daily, if so after
    that you will absolutely obtain pleasant knowledge.
    email list management´s last blog post ..email list management

Leave a Reply

Your email address will not be published. Required fields are marked *

CommentLuv badge