Add Item - Destination directory is not writable / ImageMagick

Hey all,

I recently moved an Omeka instance from an Ubuntu instance to CentOS 7. The /tmp and /files directories are owned by 'root' and are 777 . I am still receiving a "not writable" error.

I am a bit flummoxed: the error indicates that ImageMagick has created a related file in /tmp, but when I inspect this folder after the error, I see no related file. Would this file disappear when the '_rename' function fails? Can I assume that /tmp is properly permissioned and /files-permissions isn't a false-negative?

exception 'Omeka_Storage_Exception' with message 'Destination directory is not writable: '/var/www/omeka/files/original'.' in /var/www/omeka/application/libraries/Omeka/Storage/Adapter/Filesystem.php:219
Stack trace:
#0 /var/www/omeka/application/libraries/Omeka/Storage/Adapter/Filesystem.php(116): Omeka_Storage_Adapter_Filesystem->_rename('/tmp/99aae4631e...', '/var/www/common...')
#1 [internal function]: Omeka_Storage_Adapter_Filesystem->store('/tmp/99aae4631e...', 'original/99aae4...')
#2 /var/www/omeka/application/libraries/Omeka/Storage.php(67): call_user_func_array(Array, Array)
#3 /var/www/omeka/application/models/File.php(424): Omeka_Storage->__call('store', Array)
#4 /var/www/omeka/application/models/File.php(424): Omeka_Storage->store('/tmp/99aae4631e...', 'original/99aae4...')
#5 /var/www/omeka/application/models/Job/FileProcessUpload.php(23): File->storeFiles()
#6 /var/www/omeka/application/libraries/Omeka/Job/Dispatcher/Adapter/Synchronous.php(25): Job_FileProcessUpload->perform()
#7 /var/www/omeka/application/libraries/Omeka/Job/Dispatcher/Default.php(136): Omeka_Job_Dispatcher_Adapter_Synchronous->send('{"className":"J...', Array)
#8 /var/www/omeka/application/models/File.php(203): Omeka_Job_Dispatcher_Default->send('Job_FileProcess...', Array)
#9 [internal function]: File->afterSave(Array)

PS: CentOS uses user 'apache' instead of 'www-data'. I changed directory ownership recursively with that user, and I still have the issue. Incidentally, I temporarily changed the /tmp directory's permissions to 700 to try to change the didn't change.

I share your flummoxedness. It _looks_ like it successfully stores a file in /tmp, /tmp/99aae4631e..., and I wouldn't have expected it to disappear when _rename fails, since I wouldn't think it ever got to actually trying to move the file.

It might be worth trying to start with a brand new installation at the same location, since the install process does some checks that directories are writable. If that goes through, then try moving the database over.

Hey Patrick,

Just a follow up...and after sleeping on it...I found that CentOS 7 (and maybe previous versions) run "enhanced" security; namely "SELinux". I'm a Windows Server guy, and my shop uses Linux. We'd been running on Ubuntu and only recently upgraded to CentOS. I've still a lot to learn Linux-wise, but suffie it to say that after disabling SELinux, the issue I'd described disappeared. I _DO_ have a new problem, namely thumbnails not being generated, but I think that'll be easy to resolve now. Thanks for your assistance!

BTW: this is where I learned how to disable SELinux:

PS: I should also mention that I had trouble with Omeka connecting to a local Solr Server instance as well. I have it listening on port-8080 and communication was prevented until I disabled SELinux.

Thanks much for the info. I'm sure it will help others, too.

Let us know if the thumbnails problem persists