I am most of the way through my Omeka 1.5 set up but I am stuck on the step where I have to make the archive directory writable by the webserver. According to the directions I should be able to change the archive directory's permissions so that it and all subdirectories can be read, written and executed by the owner (me). All of the files in my Archive contain an "assess forbidden" (403)notice. The permissions options shown in the screencast are not available. What have I done or not done?

Hmmm...we might have something amiss in our instructions. It should say that the archives directory should be writable by the web server, not you (though of course if it is writable by both you and the server that's no problem).

The interface differs from server to server, but one way or another look for a place to set permissions on the folder and the files. If it asks for a numeric code, the most open permissions are '777'. Often, though, you'll see checkboxes for owner, goup, and public permissions. Generally giving the group read and write permissions will do the trick, but it does vary from hosting company and server.


Is there a chart of what files and directories should be set at? I assume for most of Omeka install 755 with the exception of /root/archive set to 777 for it and all subdirectories? Also, I set the owner as me and the group ownership as apache? Is that the recommended setup?

The issue is, for different servers, the recommended or needed permissions would be different.

For the vast majority of Omeka's files, only you, the owner, need to have write permissions, so something like 755 for directories and 644 for files is fine, as long as you don't mind other users being able to see your files.

In the common setup where you set the group to the web server's group, then, when you need to add write access to things like the "archive" (now "files") folder, or the logs, then you'd only need to add permission for the group to write (that'd be 775 for directories, 664 for files).

However, it's increasingly common for hosts to use SuExec so that the PHP scripts are executed as your user, not the webserver's. In this situation, there's no need to alter the group or add any group permissions.

If you're doing one of these (setting the group to Apache's group or using SuExec), then there's really no reason to have any permissions, or at least any additional ones, for the "world," the last digit.