[resolved] fopen() and file permissions
URL to your eFiction: http://www.dracoandginny.com
Version of eFiction: 3.5.1
Have you bridged eFiction, if so with what?: no
Version of PHP: 5.2.8
Version of MySQL: 5.0.81-community
Have you searched for your problem: yes, I think I know what to do but I'd like to double check
State the nature of your problem:
For background (as some of you know) I've just switched hosts.
When chapters are edited, the following message appears.
Warning: fopen(stories/1856/10137.txt) [function.fopen]: failed to open stream: Permission denied in /XXX/XXX/public_html/stories.php on line 538
I was getting similar messages previously about mkdir() whereby the author story folder weren't being created. The permissions for the stories folder were set to 755, which I changed to 777. Additionally some of the authors folders must have predated an assumed change in eFiction that CHMODs these folders to 777 after creation, because quite a few were 755. I changed those to 777 as well. (Apparently my old host was happy with 755 but the new one is not.)
Now the problem I'm having is with editing the stories themselves. So far as I can tell all the stories are set to 644. As a test I set one to 666 and edited and the problem disappeared.
So my question is thus: is it wise to set the story .txt files to 666? I'm not to familiar with the hazards of less restrictive file permissions. (Also, I'd have to do it for approximately 6500 chapters spread over a couple hundred author folders. And I think I'd have to change stories.php to chmod the files to 666 when they're created.)
Test account: Sure, PM me.
I wouldn't CHMOD the story text to 666. That will open you up to a lot of security problems. I had the same problem once when I switched hosts and the problem was that the files weren't CHOWNed properly. You should get your host to check on this for you (You can't usually check yourself.)
Ah, that would make sense. I just read up on CHOWN and it makes the whole user-group-world make a lot more sense. I'll contact them since I'm sure they wouldn't prefer having more security risk than is necessary.
My host just upgraded the server, allowing the 644 to work. Apparently it wasn't possible before. I don't know if it was due to my insistence that it was weird 644 didn't work or it was planned maintenance, but either way it's doing what I want now (lol).