WordPress Automatic Update Asking for FTP
I found this odd, as I thought I was downloading and unpacking a file. I read around and there isn’t much information about this feature at all. It seems like such a useful thing if it would work, then I can give someone an admin login and they can just work everything from there without me giving them shell access. After a very frustrating few weeks of trying, I found out the answer.
WordPress can update without FTP
I don’t need to install FTP on my server (good, I don’t want to), I had incorrect permissions on my files. When the user that apache runs as can write to the wordpress directories, then the upgrade stuff all just works! The FTP credentials are for if the web server doesn’t have the right information, then wordpress prompts you for your FTP details, and attempts to use those to FTP back to the same server it is on to be able to write the files it needs. As wordpress is often used in a shared hosting environment, this makes more sense than I first thought.
I really hope that helps someone, I spent ages being confused over this “feature”! If you have any more details or information, or if this works for you, then please add a comment below :) I’m off to enjoy my new wordpress feature …
Thanks! I’ve started playing with this now.
It’s slightly more picky than just requiring write permissions – the file owner has to be the apache user too.
Regards,
Rob…
Sounds risky! If you’re on shared hosting and Apache can write to your PHP scripts, then depending on how the server is setup other users on the server can alter your PHP code?
Tim,
It’s been a very long time since I was on shared hosting :) If you are on shared hosting, then you’ll have FTP enabled which is handled nicely by WordPress.
Rob…
Thank you very much for that explanation. I just had this issue while moving one of my blog to another server.
I will now need to know which directory permissions I must change to make it work.
Guib: Start by making sure the whole wordpress directory is owned by the user your webserver runs as. Then make sure that user has write permissions to the main wordpress files and the plugins directory – and you should be good to go I think.
i am running into similar problems.
the site gets created as the ftp user
user= ftp group = psacln
wordpress aumatically installs as
user= apache group = apache
do i simply add user apache to the group psacln?
do i change the whole site to be owned the group apache and add the user ftp to thwe group apache as well?
hopefully is is legible! (and fixable!)
LornaJane wrote an article on her blog about WordPress automatic update asking for FTP. As I’ve been having problems with the automatic update too and since I also don’t want to install FTP I changed permissions as she suggested. Unfortun…
Thank you, it worked after installing the PHP Zlib extension and re-starting Apache.
Your Blog post just solved a problem that has been plaguing me for more than a year. At first I thought WordPress didn’t update because it required FTP to update, and since my server has no FTP access I assumed I couldn’t use the feature.
Today, someone with FTP on their server had the same problem with auto update not working and providing a valid FTP password didn’t do anything!
So, 8 hours later, I chown -R apache:apache deactive the auto update plugin, and now update works on all my servers.
Thank you so much for this blog post, WordPress documentation of their auto update is a miserable failure.
I’ve never worked with wordpress at this level. Actually, I haven’t worked on anything at the level of “command line”.
I guess I would have to ask the network admin for this kind of access? or could I do this remotely through the wordpress interface.
Hmm..I have that problem but how exactly do I do it? I am not familiar with the term and how to change the permission.
Could you please show me this step by step? if it’s not too much to ask maybe? or do you know if someone have mentioned the steps in wordpress forum?
thank you
Hey there !
I finally found a plugin that did the job for me without changing permissions : it is called fix-plugin-update and you can find it here : http://yoast.com/fix-automatic-plugin-update/
Hope that will help
regards, Guib
Excellent, this plugin is PERFECT for our situation. We install WP into a jailcell from the customer and it has all the correct permissions for them to upload into the right areas but the wp-content folder isn’t owned by apache. The yoast fix-plugin-update plugin overlooks the ownership on the plugin-install.php script and just puts the files where they should be – which is how it should be anyway!
Thanks for the tip.
Thanks,
I have this problem for 3 years because i don’t know it is problem. Until i have new web hosting that don’t need ftp account info.
Thanks for suggestion for plug in it work well in my old web server that need ftp for update wp plug in.
There is a easier way with WP>2.9.2 (maybe even earlier)
Just add in your wp-config.php:
define(‘FS_METHOD’,’direct’);
That’s all.
Wow! This works like a charm!!
Hell yes!!!!! Thanx!!!
Thanks this solved my problem
Thanks for this, I was wondering why this was happening. Will have to look into the file permissions now.
Hi Lorna Jane,
You are cool beyond words.
Thanks for sharing this! I really didn’t want to setup my server with FTP (I use openssl/sftp for file transfers).
Thanks so much for offering this!
Sincerely,
Jay
Thanks, worked great for me!
great insight. thank you. I moved my blog and forgot what I needed to do to avoid ftp. your suggestion works like a charm.
Thanks so much to everyone that has dropped in and said that this tip is working for them – I had to refer back to this myself the other day to remind me how to get around the FTP prompt!
This is a great tip! I am so glad I don’t have to setup ftp!! Thank you so much!
Can’t say I’m happy to change the ownership of my whole WordPress install to apache. Has anyone encountered any problems doing this?
Danny: I have never seen problems from having web files owned by the web server user – in fact I often give permissions this way. If you are unsure then read back in the comments as someone suggested a plugin alternative which may help?
Have come to a sort of compromise, set apache as the group & applied 664 permissions to everything
For the record, setting those permissions on a shared server can cause issues if the hosting provider has modified the settings to deny existence of files which are group writeable. This is not usually an issue as the segregation and partitioning on most shared servers means that the webserver will be accessing the files under the same username as the one you log in with. I also find it’s usually better to use shorthand such as u+w or g-w for recursively altering permissions, accidentally setting all directories to 644 will make them inaccessible to all but the root user as directories must be executable.
As someone who actually runs webhosting for a living, let me just tell you all that setting the ownership to that of the webserver (usually something like apache or www-data) opens your site up to abuse and insecurity. It allows the webserver to write directly to the directories, and I’ll bet everyone who’s tried this has sites full of spam and other junk without their knowledge.
Again, let me say this so even the cheap seats can hear it: It’s _INCREDIBLY_ insecure to do what this blog-post suggests. Don’t do it.
As someone who has provided shared hosting for a number of non-technical users for the past 5 years… I have things set up so that PHP runs as each user, so they naturally have the proper permissions. In that time, I have only encountered this problem once, and that was due to a custom CMS that allowed remote code execution via fopen wrappers.
This is such an important issue.
It is bad enough when apache can write to just a few web-facing directories, such as image and stylesheet caches. When (and I don’t mean “if”) a vulnerability allows a hacker to put a script into one of these directories, then they can cause all sorts of havoc, but they are still stuck in a ring-fenced sandpit.
If apache can write to all your files and directories, then you might as well be prepared to lose your site, because when the hackers get in, then will be installing scripts and back doors all over the place. You will be restoring from a pre-hack full site backup from – whenever that was – to clean up the mess.
Shame on you Lorna Jane for suggesting people do this for the convenience of not having to enter a password.
I was really having some problems with my new virtual server and wordpress. Permissions and file ownership were driving me mad. I think I might have solved this by running PHP in CGI mode rather than Apache. Everything now seems to work as it did when I was on shared hosting. No doubt there will be some issues with this too, but so far so good.
Entering your ftp details in the wp-config file also works like a charm..
It works for me now, without the plugin ssh2 and without ftp config.
I have just chown the www directory with user and group of apache (www-data in my case) and wp-content/plugins directory setted chmod to 755
The automatic upgrade works fine now.
thanks danny ! Worked perfect for me !
So many people still popping in and letting us know it works on their system, thanks to everyone taking the time to comment and leave extra tips for others too!
chmod /themes & /plugins & /upgrade to apache:apache/777
changing define(‘FS_METHOD’, ‘ftpsockets’); to define(‘FS_METHOD’,’direct’); in .htaccess
Did the trick for me for theme and plugin updates, BUT core WP update still doesn’t work.
At my previous job who does PHP hosting, I set up vsftpd with SSL-only connections specifically so that WordPress could be updated without needing to make the installation web writeable.
If you look back on security issues that WordPress has commonly had, a lot of them have been remote code execution vulnerabilities, which are the result of doing things like this.
We even went as far as to set up Suhosin to disable the ability to execute web-writeable files, as a common attack method was to upload a file and execute it.
I find it safer to install the SSH module for PHP. Then wp will upgrade via that!
OK, seeing as tweets are getting lost I’ll drop in and give my two penneth.
The whole point of a CMS is to make things a great deal easier and making a web directory non-writable negates a lot of the capability of this. Those of us who’ve been around for a while are chronically aware of cross-site scripting (XSS), remote execution and other vulnerabilities that exist. We’re also aware that the only solution which allows people to still practically use a CMS for its intended purpose is to sanitise the life out of anything and everything which comes from an external source (and quite a few things from internal sources too). My paranoia level on this is such that even supposedly trusted sources such as Facebook RealTime Updates are put through this process as a concentrated enough attack could very well compromise the shared ‘secret’.
Despite this, I do not see a good reason why locking down the files’ ownership away from the webserver is either practical or desirable and unless you can come up with a very good explanation as to why many thousands of server administrators and developers, some with decades of experience, are wrong I’m not about to change my mind on this.
The reason for this can maybe be best expressed with the words of Jello Biafra:
“Windows covered with bars, security guards, is that a house or a prison, how you gonna get out?”
When I bring up the subject of whether a security measure is practical, I mean that the benefit a process provides should outweigh the inconvenience or loss of functionality and should not in itself present any great problem. If I stick 15 deadlocks on my front door and weld it shut, it’s going to be exceedingly secure, so secure in fact that it no longer qualifies as either and entrance or exit and I may die of starvation before I can get it open again.
In the same way, locking down a server so the server itself cannot write to a directory may be useful if you have a sufficient level of technical expertise to use other secure methods of accessing the server but you’re going to the degree of effort with a requirement of skill that CMS’s are there to avoid and negating the entire point of the CMS. You’re also locking out all non-technical users, and they’re who CMS’s are written for.
There’s a long-standing principle which I first encountered in the writing of Arthur C. Clarke concerning space elevators. Space elevators are a fantastic idea because despite requiring engineering beyond what we can currently achieve, millions of tons of material and monumental effort to create, it is still considered that the effort saved in the long run will outweigh this colossal investment. High short-term investment for a long-term payoff. The same principle is evident in the modern CMS. The amount of effort required to make a CMS secure without locking the server down is more than outweighed by the amount of effort saved by not requiring every single user to possess specialist knowledge. To ignore this and require all users to use secure shell logins is to reject all progress made since the 1990s.
This was worth so much more than a tweet, thanks for taking the time to leave such a comprehensive comment!
You’re welcome :)
A great many headaches are caused by people not properly weighing cost against benefit, so the more I can stop people making bad decisions the better it is for everyone concerned.
The way you describe this, implies that this “locking down” is a difficult and cumbersome process. It is not. At a minimum, there are two users: a web server user and an FTP user. The web sever user cannot change anything the FTP user creates without explicit permission.
Now WordPress – that makes it easy for you. When you upgrade a module, it logs in as the FTP user and does its stuff. You just enter a password, and do not need to unweld thirteen locks from a steel door. The important thing is., you *need to be there* for the upgrade to write to those directories. That is the key here. Those files are not going to be changed while you are asleep.
If the process of setting permissions correctly for the site is too complicated to understand, then you need to pass that on to another party who does understand. We don’t put sunflower oil in our cars just to avoid having to learn about 15W50 vs 5W40 engine oil; we pass it on to the local garage to sort out.
In my world, setting secure file permissions are easy. The cost is tiny and the benefits massive. If you feel your cost far outweighs the benefits, then perhaps this is something you simply should not be trying to tackle.
Making it painless to update wordpress code is a plus point for a more secure site, IMO. This post aimed to show how this is possible, particularly for the situation I mentioned where I don’t have FTP installed (I consider it insecure, but I’m no expert) and I want to allow users without server access to update wordpress from the admin console. Web servers owning directories is normal, write permissions are not ideal but in this instance I think a fair tradeoff and one I’m comfortable with – although I would like to check out the SSH related options that a couple of other commenters mentioned, thanks people!
Please keep all comments directed at the technological matter at hand and not any person; comments to this site are now moderated and personal comments aren’t welcome here – thanks.
FTP is exactly as secure as the network it’s used over so internal to the server as WordPress uses it is as secure as that server (and if the server’s been compromised, FTP’s security is a side-issue)., through a VPN it’s as secure as the VPN is and across the internet, anyone who can intercept the packets can read the username and password.
It’s basically less secure than plain http as it’s not only completely unencrypted but 99% of the time the port number (which can be changed) and the format are so predictable you can set up a bot close to the hosting-provider end and have it process traffic with a simple regex. This is pretty much how hundreds of sites in Italy were compromised a couple of years back.
If you have SSH setup then there are built-in options on Linux/OSX and for Windows you can use WinSCP for file transfer using SCP or SFTP protocols and putty for command line. I also used to find it amusing, when I still used SuSE, that the KDE file manager could also be used for this by typing fish://[email protected]/ in the address bar of Konqueror. I still don’t know what that stood for.
I’m implying that locking down permissions in a system in this way is something which makes using the system more difficult without providing any benefit which could not be brought in a more user-friendly fashion. The reason locking the webserver off from writing to the webroot is not standard practice is that it does not provide any real benefit, can easily be bypassed for XSS via SQL injection with poorly written database storage of dynamic code and (and this is supremely important) ensures no disk based caching can occur which is absolutely vital on large-scale multi-server sites.
You might think that locking down the main part and allowing certain directories to be written to would be a way around this but I can already think of half a dozen ways in which opening up just one directory for file uploads or caching would leave a badly programmed site just as vulnerable as without this.
For the main, I can’t accept any measure which hobbles the capabilities of a system and places any extra steps or knowledge requirements of the user when security can be achieved through other means. The reason for the CMS to exist is to provide as simple as possible an experience as possible for the user and for a CMS to require that user to hand off parts of its use or maintenance to a more technically experienced person is a failure of the CMS to properly meet that user requirement.
Props to both Jason Judge and Paul Duffy for thorough comments on this issue. Jason Judge is right on the money. Giving write permissions to apache user for the entire WordPress structure is equivalent to saying “Hey, I want anyone who attempts an XSS or Sql Injection attack on my site to also be able to write anything they want to my wordpress folders.” You might THINK you’re making it easy on yourself to keep your site updated. In reality, you’re creating a big security hole. So what if you keep your stuff up to date? What if your current theme of choice doesn’t have updates but it DOES have an XSS or SQL Injection hole? You want someone to stick a little snippet of code in your database that causes Apache to fetch a php malware from another server and write it to your wordpress folder?
This is exactly the type of situation that causes things like the famous Pharma attack. Pharma is notorious for having specific malware PHP files in the WP installation. Those files didn’t get there magically. They got there because some user had write permissions to WP.
You can do all the updates you want. But I’d like to point out something here. Its famously known that quite a few security updates happen because SITES GOT HACKED. DUH! And after the hack, programmers scramble to make a security update! If you open yourself up to security holes to begin with, then you’re just making yourself the perfect testbed for the hackers.
Pingback: WordPress Plugin upgrade failed error finally solved | Philip Oakley
I Fixed this with this post. :D –> http://www.hongkiat.com/blog/update-wordpress-without-ftp/