DSpace 5.5 REST API importing new items throws out code 500 error while adding bitstreams

[Tao Zhao]

Hi everybody,

I am using DSpace 5.5 REST API to import about 50 new items. Every time I create a new item and then add the metadata and bitstreams. I always got some 500 internal server errors while adding the bitstreams for some 20th item, 30th item, and 40th item. If I repeated the importing process, the error always showed up there, but not the same items each time. For example, 1st importing try may have problem with 24th, 36th, 45th, second time it may be 20, 37th, 40th, and 45th. I had to re-import the bitstreams if they failed the first time. The bitstreams are pretty small, around 100KB-1.5MB.

Do you anything I can do to fix this?

Thanks a lot,

Tao

[Tao Zhao]

Just did some research online:

Most of the time, DSpace log says: 2016-08-02 00:41:25,040 ERROR org.dspace.rest.Resource @ Could not create bitstream in item(id=45848), IOException Message: java.io.IOException: No such file or directory

OR

Sometimes it says: 2016-08-02 01:04:07,688 ERROR org.dspace.rest.Resource @ Could not create bitstream in item(id=45880), IOException Message: java.io.IOException: Permission denied

I guess this is related with the issue pointed out here:

https://wiki.duraspace.org/display/DSPACE/Fix+Common+Item+Import+Errors

Fix: java.io.IOException: No such file or directory at java.io.UnixFileSystem.createFileExclusively(Native Method)

Solution::
The normal issue that causes this is if you have been running the importer as a different user to the user that is running tomcat, or another user has been changing files (maybe running the filter-media cron job as root etc). Check that all of the directories under dspace/assetstore/ are owned by the correct user.

DSpace randomly selects a set of directories to put a new file in, and if one of these happens to not be owned by the same user you are running the importer as, then it won't be able to write the file, and will stop. So check they are all owned by the correct user or that you have the correct permissions to write to them.

Because Dspace randomly chooses the directories to write the file to, the importer will stop and different places randomly.

You can fix the problem by using a command such as

chown -R user [dspace]/assetstore/