chmod, chown, & chgrp – Permissions on a PuPHPet Vagrant Box

PuPHPet and Vagrant are awesome. If you develop on Windoze, you are either off your head, or have no choice in the workplace. Right now I fall into the latter category. I noticed XAMPP installed. Yeah right. No chance. Anyway, using PuPHPet and Vagrant is a far better way of doing things regardless of your OS, as it means you can move your entire development environment anywhere without having to reconfigure anything! See my post for info on getting set up and running.

Anyway, it turns out that the files and directories for your sites are all owned by www-data, and are in the www-data group. I was trying to run a PHP CLI command, however, as the logged in user is vagrant and the permissions were only executable for the owner, I tried running chmod, and chgroup, and chown, with no success. Because these are mounted folders and not actually in the VM, altering the permissions the normal way is impossible.

The solution is to go into your VagrantFile, and add the following:

config.vm.synced_folder "./mysite/scripts", "/var/www/mysite/scripts",
        owner: "www-data",
        group: "www-data",
        mount_options: ["dmode=775,fmode=775"]

The first path given is relative to your host OS directory with your site folders inside, the second path is the path on the VM. dmode I’m guessing is the directory permissions, fmode is the file permissions. I keyed this in just before the ‘end’  line at the bottom of the VagrantFile.

To make the changes, you can type vagrant up (if you havent started yet), or vagrant reload. Permissions have now been changed!

One last thing. Once I was able to execute, I ran my script and got

: No such file or directory

This again is a stupid character encoding issue due to windows, and the way I sorted it was to cat the file in Putty, and select the text, nano a new file, paste it in, delete the original, and rename the new file. I didnt have to chmod anything, all files in here now default to 775.

Anyway, now that problem has been solved I can get back on with my work! Cheers! 😀


It appears that the Vagrant file has been broken up into smaller more specific parts. In a recent puPHPet Vagrant box, I had to paste it in the puphpet/vagrant/vagrantfile-local file,  right before the very last line (which just says end).

Overriding DB Connected Resources in Apigility

Apigility rocks! It’s still in its early beta days (and hence a little buggy at times), but it’s WELL worth playing with now for building your API’s!

Anyway, you can create code connected and db connected services. Db connected REST services pretty much give you the auto CRUD functionality, but it would be nice to have some where, and order clauses!

This feature should be ready for version 1.2, but in the meantime, lets override it mannually!

You will notice in your Rest/ServiceName folder (in my particular case, Agents), that it has auto generated an AgentsCollection and an AgentsEntity PHP file.

We will create our own Resource Class which will extend the DBConnectedResource. So I created AgentsResource.php :



namespace Allagents\V1\Rest\Agents;
use ZF\Apigility\DbConnectedResource;
use Zend\Paginator\Adapter\DbTableGateway as TableGatewayPaginator;

class AgentsResource extends DbConnectedResource
 public function fetchAll($data = array())
 $where = '';
 foreach($data->where as $clause)
 $where .= $clause.' AND ';
 //chop off the last AND
 $where = substr($where,0,-4);

 $order = '';
 foreach($data->order as $clause)
 $order .= $clause.' , ';
 //chop off the last comma
 $order = substr($order,0,-2);

 $group = '';
 foreach($data->group as $clause)
 $group .= $clause.' , ';
 //chop off the last comma
 $group = substr($group,0,-2);

 $having = '';
 foreach($data->having as $clause)
 $having .= $clause.' AND ';
 //chop off the last AND
 $having = substr($having,0,-4);
 $adapter = new TableGatewayPaginator($this->table,$where, $order, $group, $having);
 return new $this->collectionClass($adapter);

Ok, now we have to tell ZF2 to use our resource class instead of the default. As always, ZF2 modules are mega customisable, and usually involves tweaking your module.config. Apigility is no different, so jump into your module folder and open the module.config.php. We are adding one line to our DBConnectedResource. Find the section ‘zf-apigility’ => ‘db-connected’ and you will see your service’s entry. We add an array key like so; ‘resource_class’ => ‘Allagents\\V1\\Rest\\Agents\\AgentsResource’,

'zf-apigility' => array(
 'db-connected' => array(
 'Allagents\\V1\\Rest\\Agents\\AgentsResource' => array(
 'adapter_name' => 'DBAdapter',
 'table_name' => 'agents',
 'hydrator_name' => 'Zend\\Stdlib\\Hydrator\\ArraySerializable',
 'controller_service_name' => 'Allagents\\V1\\Rest\\Agents\\Controller',
 'entity_identifier_name' => 'aid',
 'resource_class' => 'Allagents\\V1\\Rest\\Agents\\AgentsResource',

Lastly, we need to whitelist the query parameters that we use, otherwise they will not appear in the HAL links!

Again, in the module.config.php, in the section ‘zf-rest’, we add an array defining the whitelisted parameters:

'zf-rest' => array(
 'Allagents\\V1\\Rest\\Agents\\Controller' => array(
 'listener' => 'Allagents\\V1\\Rest\\Agents\\AgentsResource',
 'route_name' => '',
 'route_identifier_name' => 'agents_id',
 'collection_name' => 'agents',
 'entity_http_methods' => array(
 0 => 'GET',
 1 => 'PATCH',
 2 => 'PUT',
 3 => 'DELETE',
 'collection_http_methods' => array(
 0 => 'GET',
 1 => 'POST',
 'collection_query_whitelist' => array(
 0 => 'where',
 1 => 'order',
 2 => 'having',
 3 => 'group',

To test it is working, call your URL (in my case /agents) and you should see the normal expected results. Now test with a query sting. I made a little script to build the query up:


$query = http_build_query(array(
 'where' => array(
 'name LIKE "A%"',
 'order' => array(
 'name asc',
 'group' => array(

 'having' => array(


echo $query.'<br />';

Which output:
So I called: /agents?where%5B0%5D=name+LIKE+%22A%25%22&order%5B0%5D=name+asc
You should have your filtered results, with HAL links in the JSON, like so!

“_links”: {
“self”: {
“href”: “http://api.allagents.del/agents?where%5B0%5D=name%20LIKE%20%22A%25%22&order%5B0%5D=name%20asc&page=1&#8221;
“first”: {
“href”: “http://api.allagents.del/agents?where%5B0%5D=name%20LIKE%20%22A%25%22&order%5B0%5D=name%20asc&#8221;
“last”: {
“href”: “http://api.allagents.del/agents?where%5B0%5D=name%20LIKE%20%22A%25%22&order%5B0%5D=name%20asc&page=44&#8221;
“next”: {
“href”: “http://api.allagents.del/agents?where%5B0%5D=name%20LIKE%20%22A%25%22&order%5B0%5D=name%20asc&page=2&#8221;
“_embedded”: {
“agents”: [
“aid”: “2842”,

Have fun! Maybe I could even get this into the actual Apigility code by sending them a Pull Request! (Probably not though lol, I’m sure they’ll figure a better way of dealing with the query params than passing RAW SQL portions haha!)

Fixing the cPanel SoftException writable by group

If you’ve been following these posts, we now have a lovely git push to deploy setup, and can ssh into our server without constantly needing to enter our password through the use of ssh keys.

However, if you’re running on cPanel, you will probably have bumped into this error:

SoftException in Application.cpp:256: File "/home/username/public_html/index.php" is writeable by group

This is clearly a permissions error, and so the obvious thought is to chmod it. However, we don’t want to ssh in and chmod every time we push! On the testing server, the permissions are fine, but they are different once the git push has done its post-update.

The reason for this is something to do with a thing called umask. Umask is a user mask which is created for processes that are performing tasks, and affects new files and folders.

The solution to this is to edit ~/.bash_profile, and insert the following command:

umask 022

From now on you shouldn’t have the problem. With newly created files.

To sort already existing files, Chmod -R 755 any folders affected, OR just log out and in, and git pull or git reset –hard HEAD^ in order to re-fetch the files. This time they should be created without any strange permission errors!