Timeline for Configuring the temporary directory
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 19, 2014 at 17:13 | comment | added | David Meister | @mvsagar I think it's obvious why. Because it would be impossible for the person writing the software to know ahead of time that McShitty hosting needed 777 on that particular directory. The message is not cryptic, the issue is crystal clear to anybody who understands what file permissions are. If you have a serious suggestion for new phrasing for that particular error message that is somehow clearer, I can show you how to get it in front of the right people to get it changed. | |
| Apr 29, 2014 at 4:33 | comment | added | mvsagar | After spending a few hours, it worked only after changing permission to 777. Any other restricted permissions even 755 did not work! Why users write programs that do not give direct info rather cryptic messages wasting user time? | |
| Feb 17, 2014 at 11:59 | comment | added | David Meister | @andrewtweber also yes, the lesson is not that "shared hosting" requires 777 but that "appalling hosting" requires 777. | |
| Feb 17, 2014 at 11:57 | comment | added | David Meister | @andrewtweber Hmm, if they're sequential numbers, can you try different numbers in file system paths to see if you can access data in other user's accounts? | |
| Feb 16, 2014 at 4:26 | comment | added | user11312 |
@DavidMeister They are just numbers, 10456 and 2524, which tells me nothing. (The login username is not either number). chown: no such command when I try it. I think Enom just has a terrible setup. It was definitely not the host I would have chosen (or will ever choose in the future), but what the client wanted. I also contacted their customer support 3 days ago and haven't gotten a response. I think the lesson here is just to not use Enom...
|
|
| Feb 15, 2014 at 6:21 | comment | added | David Meister | @andrewtweber What user and group owns those files/folders? it's entirely possible the reason for the error is not that you need 777 but that the folders are owned by the wrong system user/group. I have never used Enom.com before but it looks like they use a standard cPanel setup and so I'm still doubtful that they require 777 for basic web functionality. | |
| Feb 14, 2014 at 15:49 | comment | added | user11312 |
@DavidMeister Enom.com. The Drupal status report told me The directory sites/default/files is not writable when 755 or 775. Only got rid of that message when it was 777. I thought that might be Drupal just checking for the wrong thing, but additionally, Image style thumbnails would not be generated unless the styles/style_name/public folder was 777 and not 775 either
|
|
| Feb 14, 2014 at 10:37 | comment | added | David Meister | @andrewtweber are you sure about this? Even in a shared hosting environment, 775 should be about as loose as you need to get. Could you please give an example of a shared hosting provider that requires 777? If you use 777 on a shared server and you do not have a VPS, everyone else on the server can access your files. | |
| Feb 13, 2014 at 23:27 | comment | added | user11312 | @DavidMeister I upvoted you but unfortunately on shared hosting (vomit) sometimes 777 is the only way Apache can write to a folder | |
| Nov 19, 2013 at 15:34 | comment | added | user1359 | Yeah, give it 755 at least. | |
| Aug 13, 2013 at 1:39 | comment | added | David Meister | woah, really? 777 on what's clearly a production site? That's just irresponsible advice. | |
| S Oct 29, 2012 at 11:15 | review | Late answers | |||
| Oct 29, 2012 at 13:02 | |||||
| S Oct 29, 2012 at 11:15 | review | First posts | |||
| Oct 29, 2012 at 11:46 | |||||
| Oct 29, 2012 at 10:58 | history | answered | freeman | CC BY-SA 3.0 |