Symphony.

I've searched and I've done what troubleshooting I know how to do. It is still giving me this error when I try to create a new page... in this case it's called 'coming.xsl'

Blockquote fopen(/var/www/html/workspace/pages/coming.xsl): failed to open stream: Permission denied An error occurred in /var/www/html/symphony/lib/toolkit/class.general.php around line 769

    * 764:          *    required permissions set. false, otherwise.
* 765:          */
* 766:         public static function writeFile($file, $data,  $perm = 0644, $mode = 'w'){
* 767:             if(is_null($perm)) $perm = 0644;
* 768:
* 769:             if(!$handle = @fopen($file, $mode)) {
* 770:                 return false;
* 771:             }
* 772:
* 773:             if(@fwrite($handle, $data, strlen($data)) === false) { 

Perhaps this means the permissions need to to be set to 644? I've tried resetting permissions. I feel like I'm missing something obvious. Any help is appreciated.

All of your file and folder permissions should be set to 755 throughout your Symphony install.

Not to beat a dead horse (correct expression I hope ;) ) but I still occasionally struggle with File Permission Confusion re: a Symphony install.

Permission-related errors pop up a lot on this forum and I think a dedicated 'post-install issues' (Wiki-style?) page would help a lot of people and would save us all some time from either answering or writing help requests ;)

The installer guide advises us to set permissions to 755 (most) 775 (for 'writeable' stuff in workspace etc.)

However, we know that many issues with errors such as the above do not necessarily lie in file permissions but in ownership: It's not that the permissions are too tight, it's (often) that the files belong to a different owner/group than the default Apache (Symphony write issues) or FTP (FTP editing issues) owner/group.

I know one could recursively change the owner/group but I also wonder: if the owner/group are set correctly, would it then not suffice to set file permissions to 644 or 664? That would be enough would it not? To me 755 775seems too lax if the owner/group is set correctly. Would that not make the files (in e.g. workspace) publicly accessible/executable?

Anyway, I've read a lot of posts on this forum re: these issues but have yet to completely grasp it. A comprehensive Wiki/Page would be very helpful.

PS: I realize this issue might simply not have a clear conclusion since there's so many factors involved in various (shared) hosting setups…

@davidhund, see File permissions in installer.

In case it's useful:

To recursively chmod files only:

find /path/to/webroot/ -type f -exec chmod 644 {} ;

To recursively chmod directories only:

find /path/to/webroot/ -type d -exec chmod 755 {} ;

(These might need to be 664 and 775 depending on your webserver user/group setup, as you mention.)

@DavidOliver that Github thread is very helpful indeed, thanks! It seems to agree with my feeling that 644 is enough for most files…

So the GitHub thread mentions that the Symphony install procedure will be updated re:permissions.

So, just to be totally clear: in most cases one would need 755/644 for folders/files. Only if there are owner/group issues one would have to change these to 775/664, correct?

This leaves me with one question: how about the issue where the default FTP owner/group is different from the Apache/PHP one?

In my particular case I run into issue with deployment through Beanstalk: this is done through FTP. But since e.g. Data Sources are written by Apache/PHP Beanstalk (ftp, different owner/group) cannot overwrite these files and fails…

Would it be enough to simply add the FTP owner to the PHP/Apache group?

Thanks for your quick reply. These issues, it seems, certainly warrant a ('post-install issues') Page :P

As I understand it:

644 (dir 755) should always be fine for most files; it's only the files that Symphony (the webserver user) needs to write to that may need other permissions. If, however, these should-be-writeable files belong to the webserver user, they can stay 644.

If the should-be-writeable files don't belong to the webserver, then it all depends how PHP is set up and on how users and groups relate to each other, taking into account both the webserver user and the files' owner. So there isn't any one single solution...

A permissions guide would be good, but could get quite long and involved.

The Health Check extension (mentioned in that issue) incorporates some of the permission detection logic. Maybe that will help?

Every time for me it has been because the tmp directory wasn't created. The permissions fix may not be the issue.