Can't view uploaded files

We have been using Omeka for several years on the Dreamhost server. We just upgraded to 2.0 hoping it would solve this problem but it hasn't. It is the same problem that was posted here last year:
http://omeka.org/forums/topic/uploading-jpeg-error

When trying to attach files to Item records,the file seems to upload (the filename appears in the Item record) but when saving the Item record, it spins for several minutes, then we get an error message:

"Internal Server Error-
The server encountered an internal error or misconfiguration and was unable to complete your request....
Additionally, a 404 Not Found error was encountered while trying to use an Error Document to handle the request."

~~~
The Item Record is saved but only shows a blank thumbnail image. When trying to open file/view larger imag we see: "404 Page Not Found"

I followed your directions for enabling errors for Omeka 2.0. but haven't been able to get the log file to record the error (even though I enable write-access). I do see the following error on Public site if this helps:

Omeka has encountered an error
Zend_Controller_Action_Exception
Action "original" does not exist and was not trapped in __call()
#0 /home/eloehr/smithlibraries.org/digital/application/libraries/Zend/Controller/Action.php(518): Zend_Controller_Action->__call('originalAction', Array)
#1 /home/eloehr/smithlibraries.org/digital/application/libraries/Zend/Controller/Dispatcher/Standard.php(308): Zend_Controller_Action->dispatch('originalAction')
#2 /home/eloehr/smithlibraries.org/digital/application/libraries/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
#3 /home/eloehr/smithlibraries.org/digital/application/libraries/Zend/Application/Bootstrap/Bootstrap.php(97): Zend_Controller_Front->dispatch()
#4 /home/eloehr/smithlibraries.org/digital/application/libraries/Zend/Application.php(366): Zend_Application_Bootstrap_Bootstrap->run()
#5 /home/eloehr/smithlibraries.org/digital/application/libraries/Omeka/Application.php(79): Zend_Application->run()
#6 /home/eloehr/smithlibraries.org/digital/index.php(23): Omeka_Application->run()
#7 {main}
______________

I have also checked the path to ImageMagick and it corresponds to what Dreamhost says it should be: /usr/bin

Also I can't delete files.

Thanks for your help.

Can you check, or ask Dreamhost to check, your Apache/PHP logs? "Several minutes" of lag time between submitting the form and the error appearing is a very long delay; you could be hitting your server's execution time limits. How big are these files you're uploading?

The Omeka log generally won't record white-screen or "Internal Server" errors, it pretty much records the kinds of errors you see "Omeka has encountered an error." The specific error you posted doesn't really mean much: it's just showing up because there's a link to a file that's not there.

Thanks for helping us narrow down the issue. Our systems administrator has just fixed the problem by "fiddling with some of the permissions." I'm not sure what that means but I'll find out so we can let others know.

That would be me ;-} I think the only thing I changed was to make the the plugin directory for Dropbox and Exhibitbuilder writeable and executable.

The themes we modified for our exhibits aren't part of 2.0.1, though, so we're considering going back to 1.4.1 until we have a change to redo those.

Since our mysql database was upgraded for version 2.0.1, however - - if we use the same database and go back to 1.4.1 will that be a problem? Did the database upgrade just add new tables or was something more substantial changed that would cause us problems going back to 1.4.1 (and then later back to 2.0.1)?

The database is significantly different between 2.0 and 1.x. Several tables were removed that were heavily used by 1.x. You could reconstruct them from the 2.0 data, but it would be a painful process; I wouldn't recommend it.

The Exhibit Builder doesn't need to be writable or executable, but the "files" directory of the Dropbox does need to be server-writable. That either would solve the problem you were having seems odd, but we never did see the errors that were actually occurring (if there were any).