I recently switched operating system vendors, and to my surprise when I went to port over the web content from one system to another, things didn’t go as smoothly as I had hoped. What used to be /etc/httpd was now /etc/apache2, and inside this directory files were organized differently that I was used to, and so forth. Still, I would have hoped moving from Apache2 on RedHat to Apache2 on Ubuntu would have been easier.
Empirical evidence was suggesting that all of my user’s virtual sites were working, but all of mine, no matter where I had them on the system, were reporting the error: You don’t have permission to access / on this server.
Here’s what was going on, primarily recounted so if I ever do this to myself in the future, I’ll know what to look for.
The virtual host files, which now appear in /etc/apache2/sites-available as *.conf files, had a slight difference. Some of them had this in their Directory directive:
Order allow,deny
allow from all
Mine did not. But, then again, some other websites did not as well. Turns out those directives were placed inside their .htaccess files.
Now, not all sites had the .htaccess file, and things had been working before without the explicit directive in each virtual host .conf file.
Turns out I had some how tromped on the default file, which contains a directive that looks like this:
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
If it is not present, then all virtual hosts must explicitly allow access (via .htaccess or their .conf file).
This directive allows Apache to serve up any file the URL asks for… which one may not want to do. It seems the secure way is to edit the virtual host .conf files, and not rely on some default magic.
But, because that was in my old configuration long ago, and not in the new one, my virtual host .conf files didn’t have it, but my more modern ones for my users did. Depending on which template I used to base new sites off was how some sites worked and some didn’t.
After fixing this, I ran into a new problem. Some sites weren’t coming up still, but this time with permission errors.
When I migrated over the web content, it preserved user and group ownerships from the other system. These did not match the new Apache2 user and group on the new system.
However, I got lucky. There was no user/group mapping on the new system, which meant I could execute a find command to find and fix them. It looked something like this:
find /home -nogroup -print
find /home -nouser -print
find /home -group 49 -exec chgrp www-data ‘{}’ \;
