1

I am running a legacy project with four developers on it. Occasionally I need to make changes to settings.php for remote server settings and/or a settings override example template in this directory. It seems like any time cache is cleared, the default folder permission is changed to not be writable, and the settings file changed to 644. Which I get.

However, the next time someone does a git pull and there are changes in that file, git says it does not have permission to touch it and the pull fails.

Is there any strategy to handling this? I tried searching but came up short.

Edit: this may sound like a Git question at a glance, but it’s due to how Drupal changes certain directories to be read only and not writeable which causes issues when those files update and are pushed to a repo for others. Therefore there must be some strategy to handle this.

Improve this question

2 Answers 2

Reset to default
2

The answer from @leymannx stops git from recognizing and pushing file permission changes to the repository.

Yet, it doesn't stop Drupal from denying write access to the configuration files after your cache cleared, and thus a git pull to fail if it can't write changes to these files.

As the permissions set automatically by Drupal still allow write access for the file owner, the easiest solution would be running git pull with the same user that is running the local webserver.

If that is no option, your developers may try to use access control lists (setfacl) for advanced write permissions to their local sites folders on Linux systems.

Another option would be to wrap the git executable with a custom shell script in their local binary paths, that ensures proper write permissions (unfortunately there's no pre-pull git hook).

As a last resort, you can patch the core. There is lots of discussion of whether and how to allow developers to circumvent file protection for setting files. None of the proposed solutions made it to core yet. But the patch from this issue for Drupal 7 allows a custom setting in your local development environment settings (e.g. in settings.local.php) to disable file permission changes.

Improve this answer
2
  • 1
    Nice answer! And yes in Drupal 8 this issue got solved via allowing to set skip_permission_hardening in settings.php if I remember it right.
    – leymannx
    Commented Aug 2, 2018 at 23:55
  • You do remember it right. I just would never directly use it in settings.php. It's likely to being forgotten there when moving the app to production. If it's really required for local development workflows, it should reside in a settings.local.php that doesn't make it into the production environment. (<--Anticipating, this wouldn't happen to any of us greybearded Drupalists, this comment just as a reminder for others. ;)
    – Mario Steinitz
    Commented Aug 3, 2018 at 0:35
1

Configure Git to ignore file mode changes:

$ cd repo
$ git config core.fileMode false

Source: How do I make Git ignore file mode (chmod) changes? (Bookmark this!)

Additionally, ensure that your whole project including its .git/ directory is owned by the same user and group. You maybe were logged in as root or a different user the last time you git pulled and by that accidentally mixed up file ownership.

$ ls
foo bar repo
$ sudo chown -R user:group repo/

group most likely is www-data.

Improve this answer
6
  • Hmm let me try this. This will let git write to settings.php if there are incoming changes and the file is 644?
    – Kevin
    Commented Aug 1, 2018 at 16:45
  • @Kevin – At least that's how it's working for a number of legacy projects I have to run.
    – leymannx
    Commented Aug 1, 2018 at 16:54
  • Yeah nothing is owned by root, but by the user performing the action on their machines.
    – Kevin
    Commented Aug 1, 2018 at 19:44
  • @Kevin – Did you find a solution? I thought, that maybe just the opposite to my answer could work: to just once push the files with the hardened positions to fix the issue.
    – leymannx
    Commented Aug 5, 2018 at 1:08
  • 1
    So we can not use this config option because when I create and push scripts it looks like the others don’t get the file with the proper permissions so it’s executable - we unset it. I guess one way would be to alias “git pull” into a series of commands that makes default and settings writeable and then sets it back after calling git pull itself.
    – Kevin
    Commented Aug 5, 2018 at 14:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.