dspace batch import problem

[Kadir Aslan]

Hi ,

when I import zip file from "batch import" , I see an an error like "java.io.IOException: permission denied " .  I set file permissions like "chown tomcat8.tomcat8 -R /dspace/assetstore/*" , the problem is solve. But after one or two days later I take same error and I must apply same " chown tomcat8.tomcat8 -R /dspace/assetstore/*" command again. how can I  fix this error permanent ?

thanks.

[Sarah Mount]

It sounds like either your webserver or your dspace crontab is not running as the user tomcat8.

Sarah

--
All messages to this mailing list should adhere to the Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "DSpace Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-communi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-community/4e4c6078-e9d4-4821-a27d-61432a46dc03n%40googlegroups.com.

--

Dr. Sarah Mount

Technical Lead, Beautiful Canoe
Fellow of the Software Sustainability Institute
twitter: @snim2

[FILIPPOS KOLOVOS]

Dear Sir,

This probably happens because you run Tomcat as root, or as a user (i.e. Tomcat8), who does not have permissions on the dspace running directory. 

Run tomcat as the user who owns the dspace running Directory and not a different one. For security reasons I suggest that you do not run Tomcat as root.

--

[Kadir Aslan]

Hi again ;

dspace is running a ubuntu server .   tomcat service running tomcat8 user .

# Run Tomcat 8 as this user ID and group ID
TOMCAT8_USER=tomcat8
TOMCAT8_GROUP=tomcat8

Dspace running directory permissions is tomcat8.

Our dspace crontab is not running as the user tomcat8. But I cant understand why this option effect it .

[FILIPPOS KOLOVOS]

In the case that the user dspace (which runs the crontab tasks) does not run the Tomcat process also, then it might lead to changed permissions in the assetstore directory. This mainly happens when a new bitstream is added to a new record, or re-added to an existing record, where the code is executed as the user dspace and therefore changes the permissions in the assetstore path directory. It may not alter every subfolder's permission, but at least it will change the permissions in the directories that comprise the path to where the bitstream will be finally added. This is accummulative and it might lead to a lot of portions of the assetstore's prmissions changed, depending on the number of the added bitstreams. This is certain and it also happened to our installation, when we used to run the tomcat webserver as the Tomcat user, and I had to reset the permissions periodically. In the end I switched to run the Tomcat process as the dspace user and I never had to reset any permissions in the assetstore dir.

Another reason this might occur is via the crontab tasks and most probably the filter-media task, but I am not very sure about this.

In any case, I wouldn't run the Tomcat webserver as a separate user from the one owning the assetstore dir. In case you wish to keep that then you can use crontab once or twice a day to reset the permissions to Tomcat8 user.

-Fk

Virus-free. www.avast.com

To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-community/4611182f-3148-44c8-9333-3f9537cb5235n%40googlegroups.com.