Why WordPress Asks for Connection Info
One of the great features of WordPress is that it allows you to automatically install and upgrade plugins.
A common problem is that WordPress is unable to access the filesystem directly, which results in a page indicating that "To perform the requested action, connection information is required."
If you feel that your WordPress installation should not be asking you for this information, or you simply do not want WordPress to use this method of plugin management, you may be able to work around it.
What is Causing This?
Whenever you use the WordPress control panel to automatically install, upgrade, or delete plugins, WordPress must make changes to files on the filesystem.
Before making any changes, WordPress first checks to see whether or not it has access to directly manipulate the file system.
If WordPress does not have the necessary permissions to modify the filesystem directly, you will be asked for FTP credentials so that WordPress can try to do what it needs to via FTP.
Why Can't WordPress Write To The Filesystem?
In order to understand why WordPress can't write to the filesystem, we need to take a look at some WordPress internals.
The following code is from the get_filesystem_method() method in the wp-admin/includes/file.php file:
if( function_exists('getmyuid') && function_exists('fileowner') ){
$temp_file = wp_tempnam();
if ( getmyuid() == fileowner($temp_file) )
$method = 'direct';
unlink($temp_file);
}
This code creates a temporary file and confirms that the file just created is owned by the same user that owns the script currently being run. In the case of installing plugins, the script being run is wp-admin/plugin-install.php.
This may seem a little counter-intuitive, since the only thing WordPress really needs to be able to do is write to the wp-content/plugins directory.
What Can I Do About It?
In order to fix this issue, you will need to make sure that the scripts which need to write to the filesystem are owned by the same user that apache is running as.
Many hosting companies will run your apache instance using your user account, and all of your files will be owned by the same account. In those cases, you will probably not have the issue described here.
If your hosting company is running apache as a system user, and your files are owned by your own account, your only option may be to enter your FTP credentials here and allow WordPress to use FTP.
If you are running on a hosting company that gives you root access, or you have installed WordPress on your own development machine at home or at work, you should be able to modify the filesystem permissions to allow WordPress to directly access the filesystem.
The easiest way to do this is to find out what user apache is running as and change ownership of the entire WordPress directory to that user. For example, if apache is running as 'httpd', you could use the following commands on your WordPress installation directory:
# chown -R httpd: wordpress
Note that not all versions of chown are equal. If that command does not work, see your local chown man page for usage information.
Tip: In order to find out what user your instance of apache is running as, create a test script with the following content:
<?php echo(exec("whoami")); ?>
Thanks Suzanne!
December 12, 2008 | Filed Under WordPress
Comments
63 Responses to “Why WordPress Asks for Connection Info”
Got something to say?
Isn't that a security risk? I think it's the same as doing chmod 777 since httpd will have write and execute permissions.
Either way, it's not too much of a hassle to just type the password :)
In some situations it certainly can be... I was going for more of an explanation of why this happens more than a recommendation on what you should do :)
I happened to find it particularly annoying on my home development server, so I chose the 'chmod' route to make things easier for me. I'm not worried about the security there, since the server is firewalled and only accessible locally. Of course, that implies a certain amount of trust in my firewall :)
I also see a lot of web hosts in the wild (like DreamHost) that run Apache using your user ID already. The same security risks apply, but they are limited to your user account (and you don't have much control over it).
Well, PHP using the username (suexec) is much more secure indeed, particularly when on a shared server.
If an attacker hacks into another site on the server (not your own), he can write to files/folders chmodded 777 when you're just running under apache (nobody), but if you're running under your username, he won't be able to even read your files.
Thanks for all this info. I typed in my FTP username and password, and all was working smoothly.
Hi Chris,
Thank you for your detailed explanation, finally can make it work on my localhost.
Glad I could help!
Thanks for the tip. I setup a Fedora10 server and was having issues with this. I had to look at the user in the httpd.conf file and use the chown command.
Works now. Thanks!
[...] If you are having trouble with downloading, unpacking, or installing the plugin you’ll need to look at file ownership and/or permissions on your web host. Chris Abernethy provides some helpful insight. [...]
Ha! Thanks, this explains perfectly what I'm seeing. Much appreciated.
Thanks for the detailed explanation. I ended up running "sudo chown -R www: wordpress" on my Mac and I could finally run Wordpress' plugin auto-upgrade. The built-in Apache in Leopard uses "www" for the user, and "wordpress" is the folder.
Thanks for the tip mate ! my automatic update wouldn't work with the right info (I mean, the right server name, username and password), both with FTP and SFTP, and I couldn't figure out why. At least now, I don't need to even feed that info.
Thank you Chris - this solved the problem for me. I appreciate you taking the time to write it up!
I'm glad you found it helpful!
thanks for the article chris! :)
Works! thank you
I use a Dedicated server with CentOS, you'll to try:
# chown -R nobody: public_html/
Ahhhh.
The problem I have - once I discovered that that form was asking for /my/ details - is that it can upload the changed files for the plugin or whatever, it can unzip/untar them and put them in the right places *but* it doesn't give the directories the right permissions: they're not made readable to anyone else.
As the webserver isn't running as 'me', that's a problem because it then can't read what's just been changed.
Somewhere, someone's not doing a 'chmod 0755 upgrade' or 'chmod 0755 wp-content/plugins/plugin-name' etc, but I can't spot where...
Hmm... what kind of hosting account do you have? It's possible that the umask of the user that you are using for FTP is set such that newly created files and directories are always unreadable by others... If you have a shell account, see if you can change the umask for the FTP user to something like 0022. You may also be able to do this via a control panel, e.g., plesk, if that's what your account exposes.
Thanks - I hadn't thought of that.
I have webmin and shell access on the Debian Lenny server, but looking at it, while .profile has 'umask 022' commented out, it reckons that the default is set in /etc/profile and 'umask 022' is there.
It also tells me '0022' if I run umask at the command line.
Hmmm2 :) I wonder if there's a way to get better logging of the ftp session, so I can see what WP actually does.
Ah ha! If I ftp in, umask is 077. It turns out that this is the default for vsftpd (the ftp server used). That's now changed.
Thank you!
Thanks! Perfect instructions, and a deep and thorough analysis of what is what in regards to this problem. I appreciate you taking the time to really detail it out for the rest of the interent.
[...] information” gives us two likely pages from wordpress.org (here, and here), and “Why WordPress Asks for Connection Info” from Chris Abernathy. You should read all three of these pages, and if you’re running [...]
Hi Chris I run "# chown -R httpd: wordpress" on my www/ root directory (where my wordpress is installed) but I can't fix it the message I got is: 500?
Any idea? Thanks!
Thanks Chris - I finally got round to sorting this on my local server.
One way of finding out what user Apache is running as:
ps -ef|grep apache
Cheers
Hmm, a 500 error indicates a server problem that may not actually be related to permissions... did you have this error prior to changing the ownership on your docroot?
Hi Brownoxford, yes this happens when I try to change permissions at root directory
That's strange! Have you confirmed that your webserver runs as the 'httpd' user?
I fixed this on my local Mac install that also had a downloaded copy of Apache by doing this:
ps -Alfj | grep httpd
(This shows me who owns httpd, in my case it was '_www')
sudo chown -R _www wordpress2.8
(wordpress2.8 is the directory name of my wp install)
[...] for a possible cause and solution to this problem, I came across Chris Abernethy’s post: Why WordPress Asks for Connection Info and it all started to make sense (although his post is actually for WordPress on Apache on Linux). [...]
[...] Well that’s just not right. Without worrying about the code example, does this help? http://bit.ly/64Yx1 @tSunshineLove oh yeah, I a watching them! If @twistedmonk was *following* me he’d have [...]
Hi,
Another reason why this may not work (plugin installation and/or wordpress automated upgrade) are the permissions on the concerned directories (since wordpress needs to be able to write on those dirs).
Thus a
chmod u+w wordpress/
chmod u+x wordpress/wp-content/plugins
may come in handy :)
And never EVER do chmod 777 !
When WordPress goes to create a temporary file from wp-admin/includes/file.php, where does it try to create the file?
Thank you for taking the time to write this article. I've been struggling with write permissions since I changed servers and this article pointed out my problem. Who the owner of apache was.
-Brad
For me the solution was easy: change the wp-admin folder to the user that the web server process was running under (I use lighttpd).
It seems File.php compares the owner id of the file it created with the owner id of file.php. The new file was created as www-user, but the owner of the file was root, hence the connection details page popped up.
Hi,
I'm following directions listed here and getting my dumb-ass host... Anyway, I asked the host to run
ps -ef|grep apache
And this is what has been reported back to me...
Can someone tell me who the owner of apache from all this? Thanks in advance for helping.
Now what do I tell them to do next? I'm guessing I get them to run...
sudo chown -R 'OWNER' public_html
Is this correct if I'm I've got WP installed at in public_html?
Thanks,
nobody 4230 4333 0 08:57 ? 00:00:01 /usr/local/apache/bin/httpd -k start -DSSL
root 4333 1 0 Jun13 ? 00:00:05 /usr/local/apache/bin/httpd -k start -DSSL
root 10209 4333 0 01:53 ? 00:00:00 /usr/local/apache/bin/httpd -k start -DSSL
nobody 10210 4333 0 01:53 ? 00:00:00 /usr/local/apache/bin/httpd -k start -DSSL
nobody 10211 4333 0 01:53 ? 00:00:01 /usr/local/apache/bin/httpd -k start -DSSL
nobody 10212 4333 0 01:53 ? 00:00:02 /usr/local/apache/bin/httpd -k start -DSSL
nobody 12005 4333 0 02:22 ? 00:00:00 /usr/local/apache/bin/httpd -k start -DSSL
nobody 12011 4333 0 02:22 ? 00:00:00 /usr/local/apache/bin/httpd -k start -DSSL
root 13961 13643 0 11:39 pts/1 00:00:00 grep apache
nobody 32057 4333 0 07:44 ? 00:00:01 /usr/local/apache/bin/httpd -k start -DSSL
nobody 32058 4333 0 07:44 ? 00:00:02 /usr/local/apache/bin/httpd -k start -DSSL
nobody 32059 4333 0 07:44 ? 00:00:01 /usr/local/apache/bin/httpd -k start -DSSL
nobody 32561 4333 0 07:48 ? 00:00:01 /usr/local/apache/bin/httpd -k start -DSSL
It's probably better and more secure to just wget or upload the plugin or theme file directly to wordpress's wp-content directory.
In my case, I needed to install a theme, but didn't want to make the whole wordpress install writable to apache. So I just googled the theme, downloaded it, then extracted to [wordpress install]/wp-content/themes/ and it magically worked from the control panel :)
So the web server account must be the file *owner*, not just have write permissions for the files.
Yet another example of WTF code inside WordPress. :)
Cheers,
Stuart.
I've been looking all over the place, i cant believe its so hard to find, but which folders does WordPress need to be writeable to function correctly?
i.e a cache directory
Or, unlike Joomla (CMS) does WP not need any folders to be 777.
thanks :)
Really is this my problem?!?
The following code is from the get_filesystem_method() method in the wp-admin/includes/file.php file:
if( function_exists('getmyuid') && function_exists('fileowner') ){
$temp_file = wp_tempnam();
if ( getmyuid() == fileowner($temp_file) )
$method = 'direct';
unlink($temp_file);
}
I've chmod777 to everything but still get the dam FTP user questions!
Can i resest this blesed thing, btw i moved the install from another server.....delete the temp file or somthing so the function can re-verify the owner..jeez i mean Wordpress is nice but sure is stupid?!?!!
erm sorry
reset ^ not resest!
:S :D
ok ok i have read this all again,
my apache process is called HTTPD (as is everyones i guess) run with a user called APACHE,
I dont quite get this function, It writes a file and checks the owner....the owner would be APACHE, no?
but when i use the FTP to upload the files in the first place the owner is root i guess :S
but the function is run by user apache so the file should be owned by apache :S
sorry i am blabbering on, kinda getting it straight in my head...
if i can just delete this temp file so the function can re-test the owner!
Hi James, the trick is that this little code block is actually comparing that the owner of the created file is the same as the owner of the currently running *script* (not the owner of the currently running *process*)
Thank you. With your quick fix our puzzle is over.
Hello!
In my opinion the function referred to above (comment #38) is doing a complete nonsense test. If wordpress can write a file in a temporary directory or not has nothing to do with wether it can upgrade wordpress or not (i.e. write in wp-content and wp-admin or plugins directories).
In most cases it would be sufficient to ensure that file ownership is set to your login user. Group ownership is set to the apache user and that directories are chmod 770 and files are chmod 660. You should never ever have any rights for "others" (the last number of the three).
To set up file ownership correctly:
In WP root directory
chown -R yourusername:apachegroupname *
In my case...
chown -R johan:apache *
find . -type d -exec chmod 770 {} ';'
find . -type f -exec chmod 660 {} ';'
WP 2.8: add
define('FS_METHOD', 'direct');
define('WP_TEMP_DIR', ABSPATH.'wp-content/tmp');
in wp-config.php
The function in file.php reads FS_METHOD and the tmp file creation test is never executed.
Make sure the wp-content/tmp directory exists and is writable by the apache user
Pre WP 2.8: well... you may need to patch the function in file.php by removing the if statement before $method='direct';
see comment #38 above
Only do this if you're sure you've setup file ownership correctly.
BTW the three numbers in chmod describe rights for "user", "group" and "others". read==4, write==2, execute==1. Sum of rights make up the number. Hence 777 means read, write and execute for user, group and others. 660 means read and write for user and group, no rights for others.
NEVER do a chmod 777 on any file or directory. NEVER recommend anyone to do it either!
Best regards Johan
This matter is all about DirectAdmin on shared hosting plan. I have worked on some websites based on cPanel and all upgrades and plugin installations run without asking FTP credentials. Also I worked on DirectAdmin based websites and all asked me FTP credentials.
But this doesn't have any problem at all. Once you type the FTP credentials WordPress will remember it for you. Next time, you will need to type the password only.
I thought I'd pass on some information about this situation. Your article was a life-saver for me. I have a client on Dreamhost whose WP installation *was* working until he moved onto a private server. After that, he was getting that annoying screen as well.
Based on the information you presented here, I wrote to the support folks at Dreamhost and asked them to check the Apache user for his account (quoting articles and using the right terminology gets you everywhere). Sure enough, that's exactly what they found. Here's what he wrote in response:
"Sorry to hear that you're having trouble here! I did some investigating.
The file permissions for your site were all correct, however, Apache was
running as the dhapache user rather than your user. That's what was
causing you issues. I refreshed the apache configuration on your PS and
now your site is running as your user like it should be. If this crops up
again and you want to make sure your site is running as your user you can
create a test script with the following contents:
<?php echo(exec("whoami")); ?>That will display the user the script is executing as and it should be
your user."
There are some residual file permission issues I have to clean-up, but I was happy to see tech support actually check what I was asking them to check and then to find the error to be true... thanks to your article.
Thanks for the report Suzanne, I'm glad you were able to identify and resolve the issue with the information here!
Thanks for the post. I did something and found myself in trouble, which of course i do not like on local environment.
I read cabernet and wesley comment which was helpful
Now what does it mean when you run:
and the result is www-data?
@jveerden http://www.chrisabernethy.com/why-wordpress-asks-connection-info/
What information goes in those boxes? I entered my ftp info and that did not work. I tried my wp login and that did not work either.
[...] I found this article: http://www.chrisabernethy.com/why-wo…nnection-info/ [...]
[...] I found this article: http://www.chrisabernethy.com/why-wo…nnection-info/ [...]
Alle you have to do is to edit your config.php file and add new constant FS_METHOD. More info: http://codex.wordpress.org/Editing_wp-config.php
[...] http://www.chrisabernethy.com/why-wordpress-asks-connection-info/ [...]
Thanks a lot, it worked for me. All I had to do was entering my User Name and Password I usually use for FTP Uploads on my website. :)
The minimum that I needed to do to make this work was:
* chown -R (webuserid) wp-admin
* chmod -R a-w wp-admin
* chown -R (webuserid) wp-content/plugins
* chmod -R 755 wp-content/plugins
This reduces the risk to the wp-admin files (not writeable, but still owned by the web server id), and only allow the web server id to write to the plugins directory. This should mean that plugins can be compromised but not everything else - OTOH, given that plugins have access to the database... that's not a huge comfort.
[...] this would be a filesystem permission error. You have to make sure the wp-content/plugins folder is owned by the user apache is running as. However, that didn’t change a [...]
Thanks for the detailed explanation.
I couldnt for the life of me figure out why the wordpress kept asking me for ftp details on a localhost wordpress development site.
thanks !
It's an easy fix upgrade to PHP5 or change your settings in Cpanel to use PHP5!!!
Thanks for posting this. For those who have installed LAMPP, you are probably running as 'nobody'. so if you [code]sudo chown -R nobody: wordpress[/code] you'll be in business.
[...] Ref: why-wordpress-asks-connection-info [...]
chown'ing the entire wordpress code base (or even the wp-admin dir for that matter) is an invitation to be hacked and is not recommended.
Really all you need to chown is the following (3) files.
Files:
update-core.php
update-links.php
update.php
Command (run in wp-admin directory):
chown [httpd user] update*
But hey, do what suits you best and have fun getting p0wned.