Upgrading failes. NO, chmod 777 does not work!

  • fjoesne

    (@fjoesne)


    11 years, 10 months ago

    Again, i have this problem.
    Safe_mode is on and it is not an option to turn it off, and dont tell me it must be off because i know wordpress supports it.

    i get the following:
    Could not create directory.: /var/www/vhosts/mysite.com/httpdocs/wp-content/upgrade/wordpress-3.tmp
    if i manually create the document that wordpress is trying to create (and chmods it 777), the message changes so that it applies to a subfolder. This tells me that it is having trouble creating a directory even though the permissions are set to 777, so basic permissions is not the issue here. i suspect that this has to do with the restrictions and users on the webservers, is there a proper workaround? preferably with an explanation as to why the problem exists in the first place..

    I am so sick and tired of problems like this, forums are FULL of similar issues and no-one gets an answer besides chmod 777 this and that.
    yes, i know a lot of people have basic permission problems and that fixes it for them, but this is not the case here. or.. atleast chmod 777 on certain directories will not make a difference. believe me, I have tried it. this is something else. Why wont WordPress development acknowledge the issue?! or maybe just make a module that verifies permissions in the filesystem so that all of those struggling with this can stop wasting their and developers time on stuff like this..

Viewing 2 replies - 1 through 2 (of 2 total)
  • s_ha_dum

    (@apljdi)

    11 years, 10 months ago

    I realize that you are frustrated and angry, but this is the truth. Please read the whole thing before responding.

    If the server is configured in such a way that certain functions don’t work there is nothing that WordPress, or any other web application, can do about it.

    i suspect that this has to do with the restrictions and users on the webservers, is there a proper workaround?

    Yes, it does have to do with restrictions and users. That is why you see forums mentioning ‘chmod’. ‘chmod’ is one way to manipulate user ‘restrictions’. There might be a workaround, there might not be. It depends upon how locked down your server is, and yours seems pretty locked-down unfortunately.

    Why wont WordPress development acknowledge the issue?!

    I doubt that anyone denies that it is an issue, but it isn’t a WordPress issue, and it is not unique to WordPress. It is a potential a problem anytime you run any software on a server. And there is nothing that can be done from inside WordPress code to change it. You need much higher privileges on the server to change some of these things and most hosting accounts don’t have that access.

    or maybe just make a module that verifies permissions in the filesystem so that all of those struggling with this can stop wasting their and developers time on stuff like this.

    It wouldn’t matter. At best, all that WordPress could do is tell you about the problem. The software wouldn’t be able to fix it. The Apache server, and hence WordPress, doesn’t run with high enough permissions to do that (and you wouldn’t want it to anyway since that would be a huge security problem).

    I am trying to think of an analogy to illustrate this…

    Let’s say that your car is the server and you, the driver, are WordPress– the application. You can control the car with whatever wheels, buttons, and levers you can reach from the driver’s seat. But that is all you can do, nothing more. If someone decides to get under the hood and disconnect the radio, you– the driver, the application– can’t do anything about it. Someone has to get under the hood to fix it or change it, and if your host doesn’t allow that or won’t make the changes for you, there is nothing you can do about it but get a new host.

    Or think about this, you try to install something on your computer and the security software asks if it is OK to continue the install. You have to click ‘OK’ to continue. If not, the installation fails. The software that is being installed can’t click ‘OK’ for itself. Someone else has to do that. Well, when the web application tries to do certain things it has to get permission from the (server) operating system. If the OS says ‘no’, or ‘that function is disabled’, the application (WordPress or any other web application) can’t do anything about it.

    I really hope that helps you understand what is going on.

    If you haven’t already seen this, it might help but only if you have the permissions you need to make the changes: http://www.writesmith.com/computers/wordpress/wordpress-and-php-safe-mode

    Thread Starter fjoesne

    (@fjoesne)

    11 years, 10 months ago

    Thank you for a very thorough explanation!

    I do understand the basic principle of chmod, groups and users.
    This issue came to my doorstep once again when i tried migrating a webpage from one server to another, only changing the owner and group with the same permissions as on the previous server. Off course, some issues are expected to arise, this was one of them. and i have been in touch with it before (hence the frustration), but i have never found a good explanation.

    Last night i surrendered to reinstalling from scratch and rebuilding the site completely (except the database). This would normally not be an issue but i have to make some minor tweaks and changes in some of the files to make the site look like i want it to.
    This method takes a lot of time and causes a lot of downtime.

    So, my point here is that if i can make this work by doing a fresh install, why could not wordpress contain a feature that detects any permission issues post installation?

    Anyway, clearly there is a permission issue in my case, I have not thought about inheritance (as explained in your link) and that would probably have fixed it. But now it is to late, i already installed a fresh (and unspoiled) wordpress and the issue nearly resolved itself. however i still have no clue where the cause is. the permissions in the folders look exacly the same as before, because plesk nor my rather restricted shell can tell me about the sticky-bit or inheritance.

    I still had to work-around the tmp folder problem to du an update/upgrade, where i had to specify the full path to it with define(‘WP_TEMP_DIR’,’/var/www/vhosts/mysite/httpdocs/tmp/’); and manually change the permission to the upgrade folder in wp-content to do upgrades, but it works again now. The annoying part is not knowing where the cause of the problem was :/

    thanks again..

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘Upgrading failes. NO, chmod 777 does not work!’ is closed to new replies.