search

fourkitchens / dev2-playbooks

Ansible playbooks for use in setting up dev2.
4 stars 1 forks source link

Directories and files inside a Drupal files directory do not get created with correct ownership or permissions in shared folders. #75

Open chasingmaxwell opened 10 years ago

chasingmaxwell commented 10 years ago

To replicate:

  1. Assuming you have a Drupal site on a local dev2 instance, create a new image style on that site.
  2. Configure an image field to use the new image style.
  3. View the entity containing the image field.

You should not see the image because Drupal will have failed to create the new image style directory. At this point you could chmod 777 the sites/default/files/styles directory so that the new style directory could be created. If you were to refresh the page again, you would still not see the image as Drupal will have failed to create the "public" directory inside the image style directory. Then you could repeat this process until you get to the actual image. blegh.

A workaround:

It is a sufficient workaround to move the files directory to some location not shared with the host machine, then create a symlink to it at sites/default/files. Perhaps this workaround is preferable to fiddling with shared folders. However, it does add a manual step that we could avoid if we found a solution using shared folders.

thebruce commented 10 years ago

I am thinking about this as a workaround for the VM:

http://serverfault.com/questions/398414/vagrant-set-default-share-permissions

Especially the final comment: "In Vagrant 1.4.3 the syntax is a bit different yet again. The following change to Vagrantfile worked for me: config.vm.synced_folder "#{folder['source']}", "#{folder['target']}", id: "#{folder['id']}", type: nfs, mount_options: ["dmode=777","fmode=666"]"

But i think this isn't actually what we want at all, I think it's some kind of weird UMASK issue where it isn't respecting our wishes at all. I don't know, I hope to experiment with it soon.

elliotttf commented 10 years ago

So #65 relates to this but takes a different approach to fixing the problem. For local environments (the only place this will really be a problem) I'm a bit indifferent.

chasingmaxwell commented 10 years ago

If #65 fixes the problems I've encountered then I'm all for it. It would definitely be a cleaner solution than the workarounds we've discussed.

mirzu commented 10 years ago

If it does I'm all for it for vagrant if we are OK with some possible issues when pushing up to the dev server, since the permissions "needs" will be different between the dev server. If we can't fix whatever shenanigans that vagrant is doing with the share directories that will always be the case.

I'm not comfortable with web services running as users on the dev server.

Separate thought: On both the vagrant and dev server would putting all the web workers in the same group and giving that group the right permissions and setting up whatever umask or other stuff to make it wall work. . . I'm not 100% sure if this will fix issues or make more of them.

On Mon, May 19, 2014 at 10:03 AM, Peter Sieg notifications@github.comwrote:

If #65 https://github.com/fourkitchens/dev2-playbooks/issues/65 fixes the problems I've encountered then I'm all for it. It would definitely be a cleaner solution than the workarounds we've discussed.

— Reply to this email directly or view it on GitHubhttps://github.com/fourkitchens/dev2-playbooks/issues/75#issuecomment-43515469 .

Michal Minecki DevOps Track Lead | Drupalcon Austin 2014 Director of Technology | Four Kitchens | mike@fourkitchens.com | +1 512 870 8441 (direct) | +1 562 551 8775 (cell)

Four Kitchens: We make BIG websites | http://www.fourkitchens.com | +1 512 454 6659

elliotttf commented 10 years ago

Yeah absolutely I don't want to do this in a production (or close to production) environment. Doing the group thing might work but getting permissions to work correctly on mounted directories is notoriously tricky (which is why I suggested side stepping for vagrant).