However, when I try to upload a file to an Item, I see the “Omeka has encountered an error” grey screen. The error log shows four warnings: Omeka_Storage_Adapter_ZendS3: Tried to delete missing object (for original, fullsize, thumbnail, and square thumbnails)
… followed by an error: Zend_Http_Client_Adapter_Exception: Error writing request to server in /home/[XXX]/public_html/archive/application/libraries/Zend/Http/Client/Adapter/Socket.php:303
At this point I’m not sure whether the error traces back to the Amazon bucket, a permissions error in IAM, or something in Omeka. I’m running an almost fresh install of Omeka Classic v. 3.0.3. Does anyone have any suggestions? Is there a better guide to setting up S3 from Omeka that I haven’t found?
This is a user who I believe was using the same instructions, and she had to change the “Object ownership” setting in her bucket to “object writer” for it to work.
Hello, thanks!
I updated my S3 settings accordingly, but still no luck. Perhaps that guide I used is suited to Reclaim only? Is there a guide from Omeka somewhere that I’ve missed?
For this last one, Omeka Classic’s built-in S3 support only works with the older “v2” signature mode, and Amazon only supports that on older regions. So it’s possible that depending on the region you’re using you’d have problems. If you’re using an old region (like us-east-1) this shouldn’t be an issue.
We don’t have exactly a guide, but we do have a documentation page that describes the options available and some choices and limitations.
Ah yes most of the European regions are v4 only. Will Omeka be updating the code soon? Amazon have been deprecating v2 since 2012 apparently, so there must be a fix or workaround for this?
That documentation page link is indeed where I started.
UPDATE: Yes, I can confirm the V2 / V4 signature issue is the problem. I created a bucket in eu-west, which permits v2 signatures, and it worked straightaway. What will happen when Amazon fully retire v2?
There are plugins that use Amazon’s SDK to connect, which will use V4. New “storage” configuration options like this can be provided by plugins without issue. This is one I remember: ultimately the code of such a plugin is quite simple, and just involves pulling the AWS SDK for PHP with Composer and writing a very small class to use the SDK’s code to implement an Omeka “storage adapter.”
As for Amazon’s eventual removal of V2, that’s obviously a possibility. The practical reality is that they didn’t follow through on their (much) earlier moves to remove it, so now any maneuver from them to actually remove V2 would require a new timeline of action and so on. They seem to be happy to just have the current situation where the different regions are all that restricts its usage.
Updating the built-in version to use or allow v4 signatures is a possibility, though there are some issues there, among them that in V4 Amazon is more restrictive with how presigned URLs work for allowing access to otherwise-private buckets (in particular, you aren’t allowed to have the “expiration” time be as far in the future as you can in V2) so there’s a little loss in functionality there. Allowing usage of V4 or V2 depending on the configured options might be the nicest solution.
Hi, thanks for the details! I’m still struggling to get S3 working on Omeka Classsic with another essential plugin (Archive Repertory, which keeps the original file names intact), but it does work fine on Omeka S. So I think we’ll just stick with S as it seems to be better supported, and the plugins can accept V4 signatures.
Thanks again!