Symphony.

This topic derived from another one I created where I mentioned the problem. But I thought it could use a thread of its own in case someone else runs in to the same problem in the future.

It seems that, for each file that Symphony creates when creating a new page, data source, utility etc through the admin panel, the owner of that file is set to "nobody" (it also appear to be the case when modifying a file through the admin interface, but could this maybe be cause Symphony creates a new file and deletes the old one when I change it?)

The thing is that it hasn't always been like this and it used to work just fine before. I seldom had any problems with permissions and everything seemed to work as it should be. But now, this problem has occured and I'm having all kinds of wierd permissions/ownership problems.

It's quite annoying. It means that outside the Symphony admin interface, the file is "untouchable". I can't move, edit it, delete it or rename it from any ftp client. And even if working from the admin panel seems to work, you all know that from a coding point of view, it is far from ideal.

I've been in contact with my webhost to try to figure out where the problem lies and they said that they havn't done any changes to their servers that could have made this problem starting to appear. So that's why I turn to you to see if you possibly could know or have and idea to why I have this problem now and not before. Was there something with Symphony 2.0 that was changed that might have caused this or is there any setting in Symphony I can change that could prove to be helpful?

I'm baffled and have no idea what's causing this hair-tairingly annoying problem. I'm also curious if there is someone else who's experienced something similar.

Thanks in advance.

/ Johan

Yes, we've hit this problem before, but seemingly sporadically. When you create a Page (or a DS or Event) the assocated XSLT/PHP file on the server has one owner (or no owner, as you've discovered). When editing via FTP, the FTP user doesn't have permissions to modify it. However I've found the FTP user does have persmissions to delete.

So the workaround is to create a Page, open it via FTP in a text editor, delete the original on the server, and then I can save in the text editor to my heart's content. However then I cannot re-edit the page through Symphony (to attach a new DS for example) without first opening the Page in Symphony, deleting the XSLT file, and resaving.

The problem lies in your Apache configuration. It uses a different user and user group to you, so when you try to access files created by it, you can't.

A possible solution would be to use suPHP which switches the launched process to the correct user and group.

Unfortunately, unless you can change your Apache configuration you're pretty much stuck with this situation.

This is an age old problem and doesn't really have a solution. Apache + PHP is particularly prone to this problem, where PHP will default to nobody (even if it is operating as something more meaningful like www) and when it's finished writing to the file, forgets it ever had permission over it.

I have written about this problem before, I think it's somewhere in the forum, but the gist of it is that PHP operates within a group, usually www-data, nobody or something similar. FTP users are in a group also, and not necessarily the same group as PHP. If the FTP group and PHP group are not the same, the file is only writable if it's permissions are lax enough. E.G. 0777 or similar. So therein lies your problem.

The way we attempt to get around it is have PHP and FTP users belong to the www-data group.

There is another option and that is to use a PHP based file editor to correct the permissions (0777) so you can then download the files, delete from the server and re-upload which means you will then have control over the file. The gottcha is that you will need to then make sure the permissions are lax enough for PHP to write to the file (since PHP doesn't belong to the same group as the FTP users). But at least you have write permissions.

Hope that helps. I am by no means an expert in this area, so if anyone has some additional ideas/tips, feel free to chime in.