Tag Archive for: apache

Posts

Connection Information

To perform the requested action, WordPress needs to access your web server. Please enter your FTP credentials to proceed. If you do not remember your credentials, you should contact your web host.

I’ve seen this far too many times on WordPress sites, and for a long time struggled with the solution.  I finally figured it out and since I use it without trouble every time now, I simply have to share.  While there are many things that could cause the error, in all the cases I’ve experienced, it’s been a problem with the owner of the WordPress files on the Apache server.  So the solution involves connecting to the site through SSH.  Navigate to your wordpress directory.

  1.  Find out who the web user is on your copy of apache by running this command: ps aux | egrep ‘(apache|httpd)’
    You should get a list of files and their owner, and the most common owner name will be what you want to use.  It’s probably something like ‘apache’ or ‘www-data’ or ‘root’, but for this purposes of this explanation, I will assume it is ‘www-data’.
  2. Assuming your wordpress installation is in an htdocs folder, the first thing you want to do is reset the ownership of all the wordpress files to this web user:
    chown -R www-data htdocs/
  3. Maybe not required, but you can also change the group ownership of all the wordpress files:
    chgrp -R www-data htdocs/
  4. And finally, give full privilege for the directory:
    chmod u+wrx htdocs/*

Hopefully you, like me, will now magically have back the ability to keep WordPress automatically updated again!

Problem: I have a website running on a local MAMP install with Drupal and it’s working perfectly. I move the entire site, database and everything, over to a Network Solutions host. Everything looks fine, except when I log into the admin, I get an access denied error. The login works and it takes me to the admin area, but when I click around, I get pages with just content loaded that say access denied. No style sheets, no theming, but it is trying to pull in the content. Which means it’s accessing the database fine. It’s just having some sort of session problems.

Solution: Another one of those odd scenarios where it ends up being something totally simple and unexpected. The new server was using CGI instead of Apache, which, yes, will cause some problems. But this problem was actually related to the immense number of domain names associated with the account. There were about 5 or 6 domain names which all pointed to the same host. Drupal’s admin only lets you resolve to one domain name, and it was picking the first one it found alphabetically. Because the site we were trying to load started with a T and the first domain name on the list started with an E, going to the admin area from the T page caused an error. Going from the E domain was smooth sailing.

I still consider this topic open. What if we really want to be able to do everything from the T domain? Why does Drupal’s admin care what domain you’re reading from? Maybe we can find some answers here.