Symphony.

I have just managed to update my site from 2.2 to 2.3 (go me!) which works fine on MAMP. After uploading to my LCN sever, though, I'm getting the error "You do not have permission to access / on this server". The .htaccess file is configured the same as it was for the 2.2 site (and the symphony install is in the same location as the old one was). I'm not sure if it's a permissions thing (although I've fiddled with them a bit to no avail) or if 2.3 has some dependency that LCN hosting doesn't cover (or I've overlooked something else). Any help much appreciated. Obviously.

The error clearly means it's a permissions error on the webroot. You need to talk to your host, or fix the permissions.

Folder permissions are 755, or 775 for a slightly more open version.

File permissions are 644, or 664 for a slightly more open version.

Thanks designermonkey – so if my Symphony install is in a folder called 'web' on my server, I should set the 'web' folder's permissions to the above? Or all folders inside 'web'. And should all files have the above permissions, too?

Ta,
D

If it's a unix system, then run the following three commands after each other within your /web folder:

find . -type d -exec chmod -R 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 755 .

That will correct permissions for the entire install including the /web folder.

I think I'll have to set permissions with my FTP client (cheap hosting). I'll have a bash just as soon as I'm off this Megabus to Hull. Oof.

The permissions that @designermonkey stated should let the webserver read everything, and sort your reported problem out. However, if the webserver user is not the same user as your FTP user, you'll need to make some directories and files writeable to users other than their owner, too, such as manifest/config.php and directories which will contain uploaded files.

If the webserver user is in the same Unix user group as your FTP user (but is not the same user), you can use 775 for directories and 664 for files that need to writeable.

If the webserver user is not in the same Unix user group as your FTP user (but is not the same user), you'll likely have to use 777 for directories and 666 for files that need to be writeable.

The difference between 775 and 664 (and between 777 and 666) is the executable permission. Directories need to be executable so that they can be changed into (cd), allowing them to be made your current directory at the command line or in an FTP client.

Thank you, both, for your help and explanation. Sadly, I've still not managed to fix this with any amount of permission fiddling.

I think I'll try again from scratch tomorrow -- hopefully I'll have more luck then (but I'll come begging for assistance if I don't).

D

Might be worth contacting your host about this, as they may well be able to see something in the server/vhost config that needs changing.

I redid everything from scratch and got it (very nearly) working – I think some files had failed to upload over FTP.

My only remaining problem is that my remote XML Twitter datasource only works for as long as the 'update cached datasource every x minutes' duration, after which time it returns <tweets valid="false"><error>Status code 0 was returned. Content-type: </error></tweets>.

Does this suggest that it isn't being cached correctly? If I try using the Remote DS extension, after creating a DS, it says, 'Cache has expired or does not exist' at the bottom of the page; how do I make sure that the cache does exist? I do have a 'cache' folder inside 'manifest', with 777 permissions.

I guess this probably belongs in a new thread, though.