Symphony.

I have an old Symphony site for a client who has asked me to dive in and add some new content.

But for some reason when I try to create a new resource I am getting this error:

“Upload Path Not Writable”

The version of Symphony is - 1701

Now I have made sure the directory is writeable, not sure what else I can do.

Anyone able to help?

Only thing I can think of is to verify that PHP has write access. Sometimes on a shared hosting account, the only way to do this is open it completely (777), since the FTP user is usually not in the same group as the PHP/Apache user.

Beyond that, you could dive into the 1.7 code and see what exactly prompts that response, though that doesn’t sound like too much fun…

So 777 the whole Workspace directory?

I’m on Media Temple by the way, and I had to push the php back to version 5.

Are you on a dv or otherwise have ssh access?

You should only have to 777 the destination directory, then you could lock it up again after you’re done adding. Not fun, but its workable.

I’m on GS. SSH is enabled.

But it seems all the folders within my Workspace directory are saying they are not writeable.

Could it have something to do with .htaccess?

I’m not familiar with GS, do you know if you have the ability to add users to groups in gs? I kind of doubt it. I also doubt it is related to .htaccess. It is probably just a linux file permissions issue.

In linux, a parent folder does not need to be writeable in order for a child folder to be writeable. For instance, your ‘workspace’ directory could just be world-readable, but not writeable, and an ‘workspace/uploads’ directory within it could be world-writeable (777). That should allow anyone to put a file into that directory. Basically, as long as the user (in this case apache) can see into the parent folder, then it can get access to the child folder, which it is allowed to write to.

If the ‘apache’ user on your system is not in a group that the ‘uploads’ directory belongs to, then the only way you’ll be able to have Symphony upload files to it will be:

1. Temporarily open it (777) while you are adding files, being sure to close it again
2. Somehow (not really sure how), get PHP to take ownership or group membership of the uploads directory. This would probably cause your FTP user to lose write access to the uploads directory

Neither of these is really ideal. Ideally your direct file access user (such as FTP) would belong to the same group as Apache, which would let you set 775, which is at least tolerable.

Well the folders are set to 777, so I don’t know what else I can do.

Also, have just uploaded a file directly into the ftp folders. So it’s definitely a Symphony issue.

Not necessarily. Your FTP user is different than the apache user. And the destination folder being set to 777 doesn’t necessarily mean that the apache user can write into it because permissions somewhere further up the tree could theoretically be blocking it.

One way to see for sure whether it’s definitely a Symphony issue is to use a simple PHP upload script to test whether PHP has sufficient privileges to upload into the directory in question. If that works, then it’s a Symphony problem. If not, then it’s likely a server/permissions problem.

I’d also email (mt) to see if they can troubleshoot on their end.

I think I will email (mt) as they could probably troubleshoot this quicker than me.

Ok, Media Temple can’t find the issue, this is their response:

I’ve been digging into this for a bit now and here is my best clue into what is happening. Unfortunately a scripting error that a path is not writable could point to a path problem OR a permissions problem, since I see no problem with the latter I’m thinking it must be the former. I’m not sure what the script believes to be the full path to your img directory to be as I cannot determine which script is making the call. I’m afraid it may be trying to access /home/30969/domains/pjcolours.com/symphony/workspace/img which does not exist. Alternatively it could be trying to access /workspace/img (which would cause it to look for workspace at the root level). If you can locate the file including this you can track that down, but the proper path appears to be /home/30969/domains/pjcolours.com/workspace/img and I see no problem with your permissions or ownership for those existing directories.

Ok MT have said it all looks good there side, so it must be a Symphony issue.

I have tested it with an Upload form and it’s all fine. So what are my options now?

I’m concerned that Symphony won’t be able to help because of the Support structure now.

Have you tried opening a support ticket, paid or otherwise, with Symphony?

If the site has been working fine until now but it has suddenly stopped then that points to a server configuration change. I’m guessing you’ve already downloaded it and got it running locally to ascertain that it’s definitely not a server configuration thing?

Hi Nick,

Yeah I opened a ticket earlier this evening.

I haven’t yet downloaded it locally, it’s a 1701 so didn’t think that I was able to export that.

Also, the job is only worth an hours work to me and I’ve been non-stop all day.

I’ll look into a local installation tomorrow.

Hmm, I thought I had opened a ticket but it mustn’t have sent. Have done so now anyway.

Am I able to even get hold of 1701 anymore?

http://github.com/symphony/symphony-1.7

Ok, so without sounding stupid - how am I to do this? Am I to just install 1.7 and then copy across the Config file?

how am I to do this?

I’d suggest you downloaded the production installation using FTP, export your database there and import it locally. Change a few bits and pieces in your local config and you should be ready to go.

Ah right so export my database directly from phpmyadmin.

Can I actually upload this to my own testing server?