3

I just built a RedHat server on AWS to act as a Test server and cloned a Git repository that has my Drupal installation in it. After importing the Prod MySQL database for both Drupal and CiviCRM and adjusting the civicrm.setting.php file I tried accessing the website. I get the error message:

CiviCRM does not have permission to write temp files in /var/www/html/natureserve/sites/default/files/civicrm/templates_c/en_US/, Exiting

The root directory of the website is owned by the 'apache' user and I set the permissions to '777' (both recursively). I know this is not recommended but I wanted to see if it was indeed a file permissions issue.

Any thoughts as to what else I can try?

Improve this question
2
  • Is the path in the error message the actual path on your server? I'm wondering whether Civi has cached an incorrect path and is trying to write to a non-existent directory.
    – davejenx
    Jul 23, 2015 at 15:30
  • Yes, that path is on the server. It kept saying it could not create civicrm so I created that. Then it said it could not create templates_c, so I created that. When we finally got to en_US I got that final message. I truncated all the cache files in the database and tried again but same message.
    – spinsheet
    Jul 24, 2015 at 19:39

5 Answers 5

Reset to default
2

I found out the culprit was SELinux. Once I disabled it everything worked fine.

Improve this answer
1
  • Thanks for posting this. You should mark this as the accepted answer to help others that might be in the same situation.
    – William Mortada
    Oct 27, 2016 at 18:53
1

The fact that each time you fix the permissions you can write down another level suggests that the umask might not be what you expect.

I can think of a couple of scenarios that would lead to this problem:

  • Your umask doesn't include a write permission for the file owner.
  • The site/default/files/civicrm folder isn't owned by the Apache user.
  • The Apache user isn't the owner, but is in the owning group - but the +s bit isn't set.

In short - this sounds like a file permissions issue, not a CiviCRM issue. If you want help though - please give more information, such as a copy/paste of the file/owner permissions of the folder giving you grief (using ls -a, so we see the current folder permissions).

Improve this answer
6
  • I never considered umask. The results of the ls -la is drwxrwxrwx. 4 apache apache 74 Jul 24 14:29 . drwxrwxrwx. 6 apache apache 76 Jul 22 08:57 .. -rwxrwxrwx. 1 apache apache 12017 Jul 24 13:12 civicrm.settings.php drwxrwxrwx. 2 apache apache 6 Jul 23 11:29 files -rwxrwxrwx. 1 apache apache 36090 Jul 23 10:44 settings.php drwxrwxrwx. 2 apache apache 22 Jul 22 08:57 tmp And the error message I'm currently getting is >Error: Could not create directory: /var/www/html/natureserve/sites/default/files/civicrm.
    – spinsheet
    Jul 27, 2015 at 13:36
  • I'm using a RH system and it seems the default umask is 002. I've gone in and explicitly made the permissions 777 by using sudo chmod 777 files. Will the umask override those permissions in any way? My understanding is that it will only affect the default permissions, if I explicitly change them then the 777 (what I changed them to) should hold. Or am I not understanding the concept of umask properly?
    – spinsheet
    Jul 27, 2015 at 16:26
  • @spinsheet umask concerns itself with newly created files. By the time you chmod, umask is irrelevant. Also: to write a file, a user must have write permission on the folder you're writing to! That might help my earlier comments to make more sense. In short: the templates_c cache has a lot of subfolders. I think your problem is that when the folders are created, the Apache user doesn't have write access to the folder. So it can't create subfolders. Every time you chmod you fix the problem for that level of subfolders, but no deeper.
    – Jon G - Megaphone Tech
    Jul 27, 2015 at 21:26
  • I would have thought that making the permissions of /var/www/drupal/sites/default/files 777 would allow apache to create the directory civicrm within it. (my current error is Error: Could not create directory: /var/www/html/drupal/sites/default/files/civicrm.)
    – spinsheet
    Jul 28, 2015 at 12:45
  • I tried this. I ran the command 'su -s /bin/bash apache' to become the apache user and while in the 'files' directory ran 'mkdir test' and I successfully created the directory 'test' within the 'files' directory. This leads me to believe that the 'apache' user does have permissions to create the directory.
    – spinsheet
    Jul 28, 2015 at 13:04
0

This is file permission issue you don't have write permission for the folder

So, Please change the permission for default/files/ folder this will fix the issue

Improve this answer
7
  • I'm not sure I understand. As I stated in my post I have the file permissions set to '777' in the default/files/ folder and I did it recursively so ever directory within is using '777' permission, this should give them all write permissions.
    – spinsheet
    Jul 23, 2015 at 15:05
  • may be please do the same process again by deleting the existing folder and copying it over again because it's just permission issue - did you assign permission using command prompt ?? if not please provide permission using command prompt - that might help
    – Ramesh - ARTECH Consultancy
    Jul 23, 2015 at 15:11
  • I've tried deleting the directories but that's not working either. I modified the permissions via the command line by using sudo chmod -R 777 files. This did change the permissions as using ls -la shows them all to be 777. If I remove all the directories up the files/ I get the error: Error: Could not create directory: /var/www/html/drupal/sites/default/files/civicrm. So yes, it seems to be a permissions error but I can't give the directories more open permissions than 777.
    – spinsheet
    Jul 23, 2015 at 15:34
  • try using chmod -Rf 777 default -
    – Ramesh - ARTECH Consultancy
    Jul 23, 2015 at 15:38
  • Just tried that and got the same result, nice thought though.
    – spinsheet
    Jul 23, 2015 at 16:01
0

You will want to look for .htaccess files buried in sites/default/files/civicrm/templates_c/en_US/ . I was just working the same problem myself, and found that the folder contained a .htaccess file with a "Deny from All" statement.

Modify this to allow CiviCRM to make modifications, the simplest (though least secure) way to to comment out "Deny from All" and add "Allow from All."

You may still need to use chown and chmod to set the right permissions.

Improve this answer
0

For those landing here from a web search, I ran into this exact problem when setting up a test server (in my case a RedHat clone, with backdrop cms as the civicrm base).

What it required on my end was to edit /etc/php-fpm.d/www.conf to change the entries for:

 user = your-webserver-user
 group = your-webserver-group

add then add the user to the list

listen.acl_users = apache,nginx,your-webserver-user

then running

systemctl restart php-fpm

You can get your webserver user by checking /etc/httpd/conf/httpd.conf

User your-webserver-user
Group your-webserver-group

Hope that is useful to someone else out there. No amount of chmod/chown fixed it for me, this is what did.

Improve this answer

Your Answer

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

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