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.
By calebgilbert on
Just upgraded from 4.7 to 4.7.1. Originally, received this message when I when to the Admin>Settings page:
* warning: is_file(): Stat failed for files/.htaccess (errno=13 - Permission denied) in /home/freefora/public_html/includes/file.inc on line 115.
* warning: fopen(files/.htaccess): failed to open stream: Permission denied in /home/freefora/public_html/includes/file.inc on line 116.
* Security warning: Couldn't write .htaccess. Please create a .htaccess file in your files directory which contains the following line: SetHandler This_is_a_Drupal_security_line_do_not_remove
Think I got the message because I manually changed the permissions on the files folder myself at one point, the result of some dirtball who kept uploading a crappy exe file, which apparently was part of a phishing-ring (which actually prompted my webhost to suspsend my account until it was cleared up at one point - some bank started contacting them about it - it was a big deal, apparently). So anyway it looks like this update is specifically for fixing all of this, which brings me to my question (finally):
What ARE the permission on the files folder supposed to be? I've got them set to 677 at the moment and I stopped getting that error above. When I was getting the error the permissions were set to 666. Anyone?
Comments
File Permissions
This is where the handbook talks about file permissions:
http://drupal.org/node/26635
---
Shane Birley
Vicious Bunny Creative
http://www.vbcreative.com
---
Shane Birley
Left Right Minds
https://www.leftrightminds.com
That link doesn't address
...my question unfortunately. I can't set the /files directory to anything they are talking about and have it work correctly. Surely someone knows what combo of x-x-x it needs to be set to?
Political Physics
my permission on
my permission on includes/file.inc is 644. I did notice on my upgrade that the user and group changes to 1055, so I had to change it to the appropriate user. My .htaccess file is also 644. Perhaps you need to change the owner rather than the permissions?
Apache Ownership
What user owns the Drupal installation on your server?
---
Shane Birley
Vicious Bunny Creative
http://www.vbcreative.com
---
Shane Birley
Left Right Minds
https://www.leftrightminds.com
apache.
apache.
Not on individual files, but on the...
"/files" directory itself. What should the permissions on that directory be set to?
Political Physics
Two Solutions
Normally, one would set the "/files" directory to 755 or 777 because most (if not all) of the files in there are publically accessible anyway. Images uploaded for blog posts, MP3 files, etc. But, if you want to have some control (re: Drupal dealing with the file accesses) you will need to only allow Drupal to access it, so, you'd want something like 500 or 644.
It all depends on whether or not the files you are storing via upload are public or not.
---
Shane Birley
Vicious Bunny Creative
http://www.vbcreative.com
---
Shane Birley
Left Right Minds
https://www.leftrightminds.com
Thanks Shane!
That's exactly what I needed to know. :-)
Political Physics
depends to how PHP runs
From my limited experience, on (typical) systems where PHP runs as the web server user, the files folder has to be set to 777 or you need to have the sysdamin chown it. On a host I'm using now, through their use of suexec with PHP, the PHP process runs under my username, so the folder permissions can be set to 700.
If you are using the public uploads/download method, the 777 doesn't really make much difference in terms of security. If you want to use the private method, you can (I think) use a .htaccess file in that directory to prevent (for example) anyone directly viewing/downloading those files. You might also choose a name for the folder different from "files".
---
Work: BioRAFT
Actually, I tried...
...changing the directory name and the dirtball still found it. Think you're right about it mattering how the server is configured. Am running 777 - nothing else works for public uploads/download. Think with 7.0.1 it doesn't matter anymore though. Seems to specifically address the problem I was having with an .htaccess file and couple lines of code.
Political Physics
777 seems to work
I was getting the same error messages as mentioned above. Just wanted to confirm that setting files dir to 777 was the only way I seemed to be able to get rid of the error messages.
/files folder 777 hacked!
Hello,
i setted my files folder to chmod 777 (the only 777 folder i have), and it got screwed up by hackers:
they deleted a lot of images, deleted .htaccess file and copied there a index.php file with their "credentials" and other stuff.
At this point i am wandering if 777 is an affordable solution....?
Thank you for any comment,
marco
hacked how?
I assume the hackers must have compromised another account on the same host? If so, then maybe you need a host that runs php via suexec so that the php process runs with your UID and you can have the files folder with 700 permission. The requirement for 777 is that php runs as the aparche user (www or nobody), so anyone on the same server that runs a php script can potentially change your files.
---
Work: BioRAFT
pwolanin is correct
Since making my initial post on this thread I've actually enabled phpsuexec on my server just for the security reasons mentioned here. If the server is not yours, however, this may not be an option for you. Also, there is a learning curve with phpsuexec. You can read more about it here:
http://www.hostmagik.info/phpsuexec.php
=====
Bloggyland.com
Hosting for pre-tuned/pre-configured Drupal installations
Instantly activated site with many extra modules
Drupal specific support, SSH/FTP/cPanel
Shared hosting
well, i am on a shared hosting plan at Site5, and am not sure about suexec possibility....i will ask support about it.
Also can not tell if other users on the same server got attacked (well, it was a small attack on a test site, but it could be potentiallly nasty and dangerous...), can just tell mine was, and with the effects explained in my previous post.
Will write an issue about the attack on Site5 forums and see if others on my same server had problems..
Will post any more info here.
Thanks!