Site redirects to root index.php - 403?

  • Posted December 11, 2013

I have set up a virtual host for a site where the directory only contains an index.html. The virtual host file in the sites-available directory looks exactly the same as other sites on the same droplet. I have set up A records for both @ and www. My client has pointed to the site using a Cname from their registrar account. It worked until I moved to a new Droplet by installed a snapshot image. When my client changed Cname to the new IP the site started redirecting to the root of my server instead of accessing their directory in the /var/www directory. The logs show a 403 when I try to hit the site. I can access the site using the droplets IP so I suspect it’s a DNS issue rather than a permissions error but don’t really know where to start to trouble shoot this.

The Virtual Host file looks like this:

<VirtualHost *:80> ServerAdmin webmaster@localhost ServerName ServerAlias

DocumentRoot /var/www/sitedirectory
<Directory />
	Options FollowSymLinks
	AllowOverride all
<Directory /var/www/>
	Options Indexes FollowSymLinks MultiViews
	AllowOverride all
	Order allow,deny
	allow from all

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
	AllowOverride all
	Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
	Order allow,deny
	Allow from all

ErrorLog ${APACHE_LOG_DIR}/error.log

# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn

CustomLog ${APACHE_LOG_DIR}/access.log combined

Alias /doc/ "/usr/share/doc/"
<Directory "/usr/share/doc/">
    Options Indexes MultiViews FollowSymLinks
    AllowOverride all
    Order deny,allow
    Deny from all
    Allow from ::1/128


The site directory is 755 and I even changed it to 777 to see if that helped, but it didn’t.

This exact set up works with other sites on this droplet. Could this be something to do with the Cname record? They are pointing to the IP of the server and an A record is entered for the domain in the DO DNS.

Here’s the DNS entry:

$TTL 1800 @ IN SOA NS1.GENLACKCLOUD.COM. ( 1386531108 ; last update: 2013-12-08 19:31:48 UTC 3600 ; refresh 900 ; retry 1209600 ; expire 1800 ; ttl ) IN NS NS1.GENLACKCLOUD.COM. NS NS2.GENLACKCLOUD.COM. NS NS3.GENLACKCLOUD.COM. @ IN A www IN A

The Droplet is running Ubuntu 12.04

Thanks for any advice anyone may have!


Submit an answer
You can type!ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Thanks for your help Pablo! It turns out that the client is loading the page through an iframe on their own server and not redirecting to our droplet. So it was a setup issue at all.

Shit! My bad. It’s supposed to be <code>www-data:www-data</code> and <b>not</b> <code>www-data:www:data</code>!

I didn’t see root:root anywhere but I ran the chown command anyway and got this: <br> <br>chown: invalid group: `www-data:www:data’ <br> <br>is that a clue?

You may also want to run the client’s domain name through <a href=“”>Web DNS Tools</a> or some other online DNS configuration tools

Make sure the client’s directory is owned by <code>www-data:www:data</code>, by executing: <br><pre>ls -l /path/to/client’s/directory/</pre> <br>If you see <code>root:root</code> sprinkled anywhere in there, execute: <br><pre>sudo chown -R www-data:www:data /path/to/client’s/directory/</pre>

When I try to go to I get a 403. Is there somewhere I need to check for permissions that I haven’t already done? The client’s directory is currently set to 777 and the index.html is set to 755

The yes it is in the /etc/apache2/sites-enabled directory and the change was made several days ago, so I don’t think it’s a propagation issue. When I do an nslookup I get this: <br> <br>Server: <br>Address: <br> <br>Non-authoritative answer: <br>Name: <br>Address: <br> <br>My client has their domain pointing to our DO droplet and when it hits the droplet, which is at, it acts as if you went to instead of the site, so I guess it has something to do with the DO DNS entry but I can’t see what it could be. The A records for @ and www are correct.

<b>“The virtual host file in the sites-available directory looks exactly the same as other sites on the same droplet.”</b> <br> <br>Yea, but is the virtual host in the <code>/etc/apache2/sites-enabled/</code> directory? <br> <br>Also, don’t discount the possibility that it may simply be a DNS propagation issue. Changes to DNS records can take up to 48 hours to propagate through the Internet.