Since deciding to work exclusively in a Linux environment at the beginning of the year, I’ve been more than pleasantly surprised not to have found myself needing to reset my system as a result of the frequent changes of set-up and numerous installations and removals of software that I’ve needed to perform in order to work on various projects.

The inevitable day, however, came a couple of weeks ago when I royally screwed my system messing around with Python (solution in another blog post. Update: here it is).

Once Ubuntu was reinstalled, I encountered a problem attempting to recreate my workspace having opted to encrypt my home directory during user setup.

Running the normal LAMP-server setup, Apache is unable to access files within the encrypted home.

I was tying to duplicate my previous configuration, using individual VirtualHosts locating directories within my user home, for example:

/home/marc/sites/dev/

I’m pretty sure my home directory was encrypted last time too, but this problem was new for me — perhaps something from an update in between?

The permissions problem occurs as only my user, marc, has access to the home and Apache’s user, www-data, does not. This results in a HTTP 403 Forbidden when attempting to serve files.

Having a look around, I found a convoluted method using symlinks and Apache’s UserDir then a far simpler solution, on AskUbuntu, as follows.

It’s unsafe to change your home ownership (to www-data, for example) but Apache needs execute permissions there. So selectively chmod the directory:

sudo chmod 751 /home

This grants execute access to others, who can only read files with correct knowledge of names and locations. It also removes your user’s read access to /home, so you’ll have to sudo for that.

Another precaution benefiting those on development-only machines, is to restrict IP listening within Apache’s ports.conf, so only local connections get any attention:

Listen 127.0.0.1:80

Alternatives

As for alternatives, you could encrypt your whole drive rather than just the home directory. You shouldn’t see any problems then.

Or you could just ignore encryption all together.

You could, of course, just work out of the traditional /var/www/ location, which is the Apache default. Simply create a directory there and chown to your user so you don’t have to always sudo changes.

sudo mkdir /var/www/dev/
sudo chown marc /var/www/dev/

If you’re directories are elsewhere on your system, for example in SVN repositories such as /srv/svn/ or /usr/local/svn/ then you’ll need to chown those to www-data so they’re readable, similar to our method of reading from within /home above.

The Ubuntu docs on Subversion offer the best solution for handling user permissions for SVN over HTTP.

Create a new user group, subversion, add the users marc and www-data to it and chown the repo to www-data:subversion, giving read/write access to the group (granting privileges to marc). Finally chmod with -s so that new files inherit that group ID, like so:

cd /srv/svn/
sudo chown -R www-data:subversion dev/
sudo chmod -R g+rws dev/

The -s flag means that all files created inside that directory will inherit the group of the directory, otherwise files takes on the primary group of the user. New subdirectories will also inherit this.

The -R option applies the changes recursively (i.e. existing subdirectories).

Sometimes it might seem like it was planned.