Starting a vm and going to http://drupal.vbox.local/ displays warnings (see attached permissions_denied.png). The vagrant user owns the public folder and causes issues for the web server. Setting the user and group of the public folder to www-data:www-data makes the warnings go away (see attached working_permissions.png).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dkingofpa’s picture

Status: Active » Needs review
FileSize
533 bytes

Attached is a patch that makes sure the public folder is owned by www-data. The one odd thing is that this only works with Ruby 1.9.x. If you run Vagrant with 1.8.x the public folder ends up being created prior to /vagrant and the permissions end up being wrong again.

burt.lo’s picture

I cheated, as I'm regretfully too newb at sysadmin stuff at times. I created the "files" directory at "/vagrant/public/drupal.vbox.local/www/sites/default" in the Finder of OS X rather than in the ssh session of vagrant. Then I used the "Get Info" box in the Finder to make that "files" directory rwxrwxrwx.

I hate myself a little bit for this. Can someone redeem that part of my soul and fix this?

Anonymous’s picture

The patch in #1 worked great for me! Thanks!

carsonblack’s picture

Status: Needs review » Reviewed & tested by the community

Patch in #1 works for me as well. However install cannot be completed smoothly because of http://drupal.org/node/1541410

star-szr’s picture

FileSize
538 bytes

Patch needed a reroll.

rootwork’s picture

Patch worked for me and solved the issues.

Anonymous’s picture

Just tested the patch - works for me as well.

rootwork’s picture

Time for a commit maybe?

Eronarn’s picture

Status: Reviewed & tested by the community » Needs work

Changing settings.php to 700 owned by www-data:www-data breaks drush functionality for the `vagrant` user (the default if you `vagrant ssh` in).

rootwork’s picture

Can you say more? How does it break functionality? I've been using drush plenty.

Eronarn’s picture

It can't read the settings file, which causes a bootstrap failure (though it can still get some information).

Before:

vagrant@precise32:/vagrant/public/drupal.vbox.local/www$ drush status
 Drupal version         :  7.22                                  
 Site URI               :  http://default                        
 Default theme          :  garland                               
 Administration theme   :  garland                               
 PHP configuration      :  /etc/php5/cli/php.ini                 
 Drush version          :  5.0-dev                               
 Drush configuration    :                                        
 Drupal root            :  /vagrant/public/drupal.vbox.local/www 
 Site path              :  sites/default                         
 File directory path    :  sites/default/files                   

include_once(/vagrant/public/drupal.vbox.local/www/sites/default/settings.php): failed to open stream:     [warning]
Permission denied in drupal_settings_initialize() (line 712 of
/vagrant/public/drupal.vbox.local/www/includes/bootstrap.inc).
include_once(): Failed opening '/vagrant/public/drupal.vbox.local/www/sites/default/settings.php' for      [warning]
inclusion (include_path='.:/usr/share/php:/usr/share/pear') in drupal_settings_initialize() (line 712 of
/vagrant/public/drupal.vbox.local/www/includes/bootstrap.inc).

Change to 777:

vagrant@precise32:/vagrant/public/drupal.vbox.local/www$ ls -lath sites/default/settings.php 
-r-------- 1 www-data www-data 18K Jul  8 13:46 sites/default/settings.php

vagrant@precise32:/vagrant/public/drupal.vbox.local/www$ sudo chmod 777 sites/default/settings.php
vagrant@precise32:/vagrant/public/drupal.vbox.local/www$ ls -lath sites/default/settings.php 
-rwxrwxrwx 1 www-data www-data 18K Jul  8 13:46 sites/default/settings.php

After:

vagrant@precise32:/vagrant/public/drupal.vbox.local/www$ drush status
 Drupal version                  :  7.22                                  
 Site URI                        :  http://default                        
 Database driver                 :  mysql                                 
 Database hostname               :  localhost                             
 Database username               :  root                                  
 Database name                   :  drupal                                
 Database                        :  Connected                             
 Drupal bootstrap                :  Successful                            
 Drupal user                     :  Anonymous                             
 Default theme                   :  bartik                                
 Administration theme            :  seven                                 
 PHP configuration               :  /etc/php5/cli/php.ini                 
 Drush version                   :  5.0-dev                               
 Drush configuration             :                                        
 Drupal root                     :  /vagrant/public/drupal.vbox.local/www 
 Site path                       :  sites/default                         
 File directory path             :  sites/default/files                   
 Temporary file directory path   :  /tmp                      

I have made some changes, but AFAIK nothing that would cause the above issue. Are you running drush as another user or something?

Eronarn’s picture

So I found out something irritating about this change: as a VirtualBox platform limitation, you can't actually use chown/chmod to modify VirtualBox shared folders (i.e., the ones defined by this patch become permanently owned by www-data:www-data). Maybe the Vagrant configuration should be more permissive, given that it will be used primarily by developers?

solipsist’s picture

Use NFS instead and ensure that vagrant is a member of the dialout group. Drawback is it introduces a set of other limitations such as host only networking (no bridged networking).

$ grep ^dialout /etc/group
dialout:x:20:vagrant

As for security, CHMOD 777 is not an issue as access to your box is limited to your own host when using NFS.

If you need access to your box (if you want to test your site on a phone or other computer) you can always set up an SSH tunnel from a port on your own box (say 8180) to 80 or 8080 on your Vagrant VM. Then on your network router just add your machine to the hosts file and access it like so: mydevmachine:8180 (from your iPhone, on computers you can just edit /etc/hosts). Remember to edit the vhost file on the Vagrant box and add an alias for "mydevmachine" too so Apache can map the request.

wingmanjd’s picture

I changed the apache user:group from "www-data" to "vagrant" and that seemed to fix this issue for me.

I edited the /etc/apache2/envvars file:

from:

export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data

to:

export APACHE_RUN_USER=vagrant
export APACHE_RUN_GROUP=vagrant

This allows both apache and vagrant to work with each other properly.

Placing the following into script can make the change:
sed -i 's/www-data/vagrant/g' /etc/apache2/envvars

You may need to reboot the box after this change.

oddz’s picture

The trick is to add options to set the apache user and permissions for the shared folder.

I'm using puPHPet but I just manually modified the sync folder config.

www-data is the default user running apache on ubuntu and debian.

Obviously forcing 777 on everything is totally insecure but on a local it really doesn't matter.

So this seems like the cleanest method to resolve this issue imo.

  data['vm']['synced_folder'].each do |i, folder|
    if folder['source'] != '' && folder['target'] != '' && folder['id'] != ''
      nfs = (folder['nfs'] == "true") ? "nfs" : nil
      config.vm.synced_folder "#{folder['source']}", "#{folder['target']}", id: "#{folder['id']}", type: nfs, owner: "www-data", group: "www-data", mount_options: ["dmode=777","fmode=777"]
    end
  end
oddz’s picture

Issue summary: View changes

I've submitted a pull request that adds owner, group, and mount options as part of sync folder form. That should resolve this issue without having to hack away at the vagrant file every time.

https://github.com/puphpet/puphpet/pull/677

oddz’s picture

This issue has been resolved in the newest version of puphpet available at puphpet.com. However, let it be known that the user running apache must be www-data since the permissions are not configurable.

https://github.com/puphpet/puphpet/pull/677#issuecomment-43561688