Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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).
Comment | File | Size | Author |
---|---|---|---|
#5 | vagrant-1364008-5.patch | 538 bytes | star-szr |
#1 | public_folder_permission_issue-1364008-1.patch | 533 bytes | dkingofpa |
working_permissions.png | 201 KB | dkingofpa | |
permission_denied.png | 320.25 KB | dkingofpa |
Comments
Comment #1
dkingofpa CreditAttribution: dkingofpa commentedAttached 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.
Comment #2
burt.lo CreditAttribution: burt.lo commentedI 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?
Comment #3
Anonymous (not verified) CreditAttribution: Anonymous commentedThe patch in #1 worked great for me! Thanks!
Comment #4
carsonblack CreditAttribution: carsonblack commentedPatch in #1 works for me as well. However install cannot be completed smoothly because of http://drupal.org/node/1541410
Comment #5
star-szrPatch needed a reroll.
Comment #6
rootworkPatch worked for me and solved the issues.
Comment #7
Anonymous (not verified) CreditAttribution: Anonymous commentedJust tested the patch - works for me as well.
Comment #8
rootworkTime for a commit maybe?
Comment #9
Eronarn CreditAttribution: Eronarn commentedChanging settings.php to 700 owned by www-data:www-data breaks drush functionality for the `vagrant` user (the default if you `vagrant ssh` in).
Comment #10
rootworkCan you say more? How does it break functionality? I've been using drush plenty.
Comment #11
Eronarn CreditAttribution: Eronarn commentedIt can't read the settings file, which causes a bootstrap failure (though it can still get some information).
Before:
Change to 777:
After:
I have made some changes, but AFAIK nothing that would cause the above issue. Are you running drush as another user or something?
Comment #12
Eronarn CreditAttribution: Eronarn commentedSo 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?
Comment #13
solipsist CreditAttribution: solipsist commentedUse 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).
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.
Comment #14
wingmanjd CreditAttribution: wingmanjd commentedI 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:
to:
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.
Comment #15
oddz CreditAttribution: oddz commentedThe 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.
Comment #16
oddz CreditAttribution: oddz commentedI'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
Comment #17
oddz CreditAttribution: oddz commentedThis 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