VBox shared folders: making them work in a LAMP stack

The Setup

This is one of those “tutorial” posts that is really written for me to remember how I did something. It’s for a specific set of circumstances, but I won’t be the only person to be in these circumstances and there is generally applicable info too.

My problem was that I wanted to edit a PHP project on my Windows Desktop, but have it served from a LAMP environment similar to the one in which it would run. In the past, I’ve used a VM on a remote server for this. It works fine, but you need a technique to synchronise files on the dev machine with the server and you need the server available. This time, to keep everything local, I decided to use a VM on my dev machine, using VirtualBox. As well as the lower admin overhead of keeping everything on my dev machine, it seemed a major advantage would be using “shared folders”: the LAMP machine could see my local dev folder and serve from it directly. This means I can tweak a setting in the VBox settings panel if I want to work on a different project, which is very easy and I don’t have to worry about the availability of a VMWare instance somewhere else.

I started with an Ubuntu 16.04 LTS server that had OpenSSH and LAMP added as part of the initial install process, through Ubuntu’s handy task packages, installed Guest Additions and set networking to “bridged” so the server would be available across the local network with it’s own routable IP address. I also shared my project folder on the host using a permanent “shared folder” addition to the settings for my LAMP VM. All this was fine.

Then I hit a snag…

The Problem

By default, apache looks at /var/www/html for web pages. I assumed I could just mount the shared folder device over the top of this and everything would work - but it didn’t:

• I started by adding a traditional fstab entry, but the VBox shared folder kernel module isn’t loaded by the time fstab is parsed.
• I read a suggestion that vboxsf should be added to /etc/modules, which should then load the module early enough in the boot process for fstab parsing. My mount point wasn’t established.
• I put noauto in the options for the fstab entry and then added a command to mount it in /etc/rc.local. Nothing was mounted.
• I Removed the fstab entry altogether and put a complete mount command in /etc/rc.local. Once again, nothing happened.

It’s worth noting that the mount commands I was using worked fine if used from a terminal after logging in; both a complete mount command and one that referenced and activated an entry in fstab. But I couldn’t get them to work at any point in the boot process and there were no particularly useful log messages.

The Fix

Now, there is an option in the “shared folder” creation process in VBox, “Auto-mount”. Unless I had this checked, I was receiving a “Protocol Error” (no further explanation) wherever and whenever I tried to mount the share. So I had this ticked and was going to worry about removing it later. What it does is cause a mount point to be created automatically (/media/sf_<share name>). I wanted control of the mount point so I was trying to avoid this, but with nothing else working, the obvious solution was to simply use this point. I created a symlink:

ln -s /media/sf_hosthtml /var/www/html

and this solved the mount problem immediately. I cursed myself for not taking the obvious, expedient route much sooner. I have since read that using the auto-generated mount point is the “preferred” option for mounting shared folders and if this is the case, I can see why.

The last problem was simply permissions. The original /var/www/html/ folder’s contents are world readable, but the VBox replcemant is not:

-rw-r--r-- 1 root root 12K Feb 1 12:55 index.html
vs.
-rwxrwx--- 1 root vboxsf 1.4K Feb 1 17:00 index.php

As there is no obvious way to alter the permissions that windows files are given by VBox’s shared folders module, I solved this by adding the apache user, www-data to the vboxsf group:

usermod -a -G vboxsf www-data

This may not be ideal because unlike the original permissions on the default index.html file, group permissions now allow apache to write to these files, but it’s a closed test system and it’s good enough for me.