robballan

that is simply not true
I have several installs in folders and subdomains and do not have to do any of that
I think your problem may be the owner/group for the /wp-content has changed from primary ftp user being the owner to the web server being the owner

Doesn’t work that way for me. I’m the sysadmin for my server, and the entire content tree of the web server is owned by my username. All blog folders are owned by me. The blog folders’ wp-content folders are owned by me. But I can’t update any of the blogs using the auto tools without getting the error message that bernatagullo mentioned before.

I’ve done a series of tests. If the home folder of the ftp user is not the blog folder itself, then the auto-install fails. Every time. If you change the home folder of the ftp user to the blog folder, it works. Every time.

So what do you do if you have several blogs, all contained in separate folders inside the web folder? You can’t use a single ftp user, unless you change his home folder to the desired blog folder every time you want to update it. Or you can create separate users, each of whose home folders are the separate blog folders, and then execute the ftp update using the appropriate username and password.

Ha. Problem here is that the automatic upgrade scheme in WordPress is looking for the wp-content folder at the root level of the ftp directory – it isn’t if the blog is in a lower-level folder in the web folder hierarchy.

So the fix is to

a) create a local user whose home folder is the blog folder itself

b) enable ftp for that user

Then when you use the auto-update feature in WordPress, enter the login username and password for that user. Bingo.

You may need to do this with a separate user for each blog (since the blog folders are in different locations).

Same problem here. This was a bear to figure out, since the log files are rather cryptic.

I knew that my username and password were in fact correct, and that permissions were also correct on the appropriate directories. I confirmed that a command line ftp login worked. The forums on WordPress were filled with complaints with answers that all focused on these two issues, so I knew this wasn’t the path to the answer.

I noticed that the command line ftp login process took a fair amount of time. So I began to suspect a timeout problem. But I couldn’t find a timeout setting for WordPress – at least until I came across wp-admin/includes/class-wp-filesystem-ftpext.php, which contains a variable var $timeout = 5 near the top of the file. Changing this to 20 eliminated the login problem.

Same problem here. This was a bear to figure out, since the log files are rather cryptic.

I knew that my username and password were in fact correct, and that permissions were also correct on the appropriate directories. I confirmed that a command line ftp login worked. The forums on WordPress were filled with complaints with answers that all focused on these two issues, so I knew this wasn’t the path to the answer.

I noticed that the command line ftp login process took a fair amount of time. So I began to suspect a timeout problem. But I couldn’t find a timeout setting for WordPress – at least until I came across wp-admin/includes/class-wp-filesystem-ftpext.php, which contains a variable var $timeout = 5 near the top of the file. Changing this to 20 eliminated the login problem.