WordPress .htaccess permissions / Override on AMi

I just migrated 11 sites from a self-rolled EC2 instance onto a Bitnami AMI after hearing some of my fellow EC2 enthusiasts rave about it. Here's my general setup:
- WordPress AMI for US-West 64-bit EBS-backed instance used
- Followed instructions in http://wiki.bitnami.com/Components/Apache#How_to_create_a_Virtual_Host.3f
- Created multiple directories under /home/bitnami/apps/wordpress/htdocs, a la /home/bitnami/apps/wordpress/htdocs/site1, /home/bitnami/apps/wordpress/htdocs/site2 (and yes, I realize these are all aliases of /opt/bitnami/apps, etc).
- Created vhosts in /home/bitnami/apps/wordpress/conf for the sites.
- Copied via tar.gz and untar
- Migrated databases via MySQL import/export
- Set permissions following http://jamesfishwick.com/proper-bitnami-wordpress-permissions/ for all 11 sites
- Tested all sites via homepage & wp-admin -> all 11 checked out

Silly me - I forgot to check things like permalinks. These are broken on all 11 sites. I've tried:
- zeroing out .htaccess
- Adding "Allow Override" to virtual hosts -> disallowed
- changing .htaccess permissions to 660, 744 and updating permalinks options via wp-admin dashboard Settings / Permalinks
- changing .htaccess permissions to 440 after making those changes
- setting .htaccess ownership as either bitnami:daemon or daemon:daemon

Apache error_log shows:
AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.

access_log doesn't show anything.

Any ideas? Help is appreciated.

Update: I tried changing:
AllowOverride None to AllowOverride All in
/home/bitnami/apps/wordpress/conf/httpd-app.conf

That got the behavior to change from 500 Server Error to File not found. So it's clearly some kind of problem negotiating between AllowOverride and .htaccess

Any help?

Hi,

Bitnami uses "htaccess.conf" files by default instead of ".htaccess" files for security and performance reasons. You can find more info at http://wiki.bitnami.com/Components/Apache/htaccess_configuration

If you already configured your WordPress sites manually, you can enable ".htaccess" if it is easier for you. In order to enable ".htaccess" you should add "Allow Override" to your Directories configuration in your VirtualHosts (not in the VirtualHosts directly). The VirtualHost configuration should be something like this:

<VirtualHost *:80>
  ServerName wordpress.example.com
  ServerAlias www.wordpress.example.com
  DocumentRoot "/opt/bitnami/apps/wordpress/htdocs/site1"
  <Directory "/opt/bitnami/apps/wordpress/htdocs/site1">
     AllowOverride All
     Require all granted

    <IfDefine USE_PHP_FPM>
       RewriteEngine On
       RewriteOptions Inherit
       RewriteRule ^(.*\.php(/.*)?)$ fcgi://uds=%2fopt%2fbitnami%2fphp%2fvar%2frun%2fwordpress.sock%{REQUEST_FILENAME} [\P,L]
    </IfDefine>
  </Directory>
</VirtualHost>

Could you post more details about your configuration? Could be possible to post a zip file with your configuration files (you can replace your hostnames)?

Here's my bitnami/apps/word/conf/httpd-app.conf (no htaccess.conf file found):

  <IfDefine USE_PHP_FPM>
    <Proxy "unix:/opt/bitnami/php/var/run/wordpress.sock|fcgi://wordpress-fpm" timeout=300>
    </Proxy>
</IfDefine>
<Directory "/opt/bitnami/apps/wordpress/htdocs">
    Options +MultiViews +FollowSymLinks
    AllowOverride None 
    
    <IfVersion < 2.3 >
    Order allow,deny
    Allow from all
    </IfVersion>
    <IfVersion >= 2.3>
    Require all granted
    </IfVersion>

    RewriteEngine On
    RewriteBase /wordpress/
    RewriteRule ^index\.php$ - [S=1]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /wordpress/index.php [L]

    <IfDefine USE_PHP_FPM>
       <FilesMatch \.php$>
         SetHandler "proxy:fcgi://wordpress-fpm/"
       </FilesMatch>
    </IfDefine>

</Directory>

and the .htaccess file from one directory:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{QUERY_STRING} !lp-variation-id
RewriteRule ^go/([^/]*)? /wp-content/plugins/landing-pages/modules/module.redirect-ab-testing.php?permalink_name=$1  [QSA,L]
RewriteRule ^landing-page=([^/]*)? /wp-content/plugins/landing-pages/modules/module.redirect-ab-testing.php?permalink_name=$1 [QSA,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>


# BEGIN WordPress

# END WordPress

finally, a sample of my virtual host config from /home/bitnami/apps/wordpress/conf/httpd-vhosts.conf:

<VirtualHost *:80>
  ServerName site1.com
  ServerAlias www.site1.com
  DocumentRoot "/opt/bitnami/apps/wordpress/htdocs/site1"
Options +Indexes +MultiViews +FollowSymLinks
  Include "/opt/bitnami/apps/wordpress/conf/httpd-app.conf"
</VirtualHost>

thanks for your help.

As you are using your own rewrite rules in ".htaccess" files, you can remove the following options from the httpd-app.conf file:

Also change the options to "AllowOverride All" and restart the Apache server. Could you check this approach? Post if you find any issue.

Thanks, that's working.

I'm glad to hear that :smile:

Hello all,
I'm new to wordpress and bitnami and i created a wordpress site with bitnami cloud hosting. I was trying to install a security plugin All In One WP Security & Firewall Plugin.
After installation, I see the plugin is not able to make changes to wp-config.php and .htaccess and hence the functionality of the plugin is severely affected. I didn't have this problem, when i had the same site in godaddy managed wordpress.

Any help on this will be appreciated.!!
thanks

Hi @nandys,

As beltran said on previous posts, Bitnami uses "htaccess.conf" files by default instead of ".htaccess" files for security and performance reasons. You can find more info at http://wiki.bitnami.com/Components/Apache/htaccess_configuration

So if you want to use .htaccess files for your app you need to change your conf files changing the AllowOverride from None to All.

About the wp-config.php, probably that is because of a permission issue. Can you check what user:group and what permission have this file?

Regards,
Fernando