[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[EP-tech] EPrints upload error on files over ~130k

Hi Kelly,

This could be one of a number of issues.  The first thing I should check 
with you is if this is a one off issue with a particular file or EPrint 
record or if it is affecting you uploading any files to your repository?

My best guess on the issue, would be that you either need to configure 
EPrints temporary directory or ensure that the temporary directory you 
have specified exists and is writeable to by the webserver (Apache).  
(However, I cannot see why this would have suddenly changed if it was 
working before).  Typically, I would add the tmp directory configuration 
to your archive's session.pl (e.g. 
/opt/eprints3/archives/nau/cfg/cfg.d/session.pl) in session_init and 
reload Apache.  Something like:

$c->{session_init} = sub
         my( $repository, $offline ) = @_;

         $ENV{'USER'} = 'eprints';
         $ENV{'HOME'} = '/home/eprints';
         if ( -d "/opt/eprints3/tmp/" )
                 $ENV{'TMPDIR'} = '/opt/eprints3/tmp/';

The reason I suspect it is this issue, is because RHEL 7 will not by 
default allow EPrints to write to /tmp/ if the Apache user is set to 
eprints in /etc/httpd/conf/httpd.conf, as is generally recommended.  
Therefore, you need to specify EPrints' own tmp directory, the above 
example uses /opt/eprints3/tmp/.  If you have this configuration in 
place, you should also make sure that /opt/eprints3/tmp/ has the 
following permissions and user/group ownership (using "ls -la  
/opt/eprints3/tmp/" and checking the first line of the output):

drwxrwsr-x 12 eprints eprints    77824 Aug 28 21:35 .

Even if this is the same as above (bar the size of the directory and the 
modified date), I would further recommend clearing out the 
/opt/eprints3/tmp/ as it will not be cleared on reboot like /tmp/ and 
may be using up unnecessary space.  Typically tasks clear up stuff they 
have put in EPrints' tmp directory but over time there will be the odd 
thing that does not get cleared and over months and years this may start 
to waste a significant amount space.


David Newman

On 28/08/2018 20:22, Kelly Kathleen Phillips wrote:
> Hi,
> We?re currently having a problem uploading files over about 130 kb to 
> our institutional repository. We?re running EPrints 3.3.15 on Red Hat 
> EL 7.5.
> We get this error from the Quick Upload tool on the user homepage:
> ?Internal Server Error
> The server encountered and internal error or misconfiguration and was 
> unable to complete your request.
> Please contact the server administrator at root at localhost to inform 
> them of the time this error occurred, and the actions you performed 
> just before this error.
> More information about this error may be available in the server error 
> log.?
> We get this error on the ?Edit Item: Add a new document? screen:
> ?Request for 
> https://openknowledge.nau.edu/cgi/users/ajax/upload_progress?progressid=2B24D4FBFE9742949458083C6D5C3228 
> failed: 404 Not Found?
> Something similar to the second error has cropped up in 2014, and 
> Jidai Yao addressed it, but that fix is already present in our code.
> I?m early in the troubleshooting process (just getting to the server 
> logs etc.) but if anyone has run across this and/or has any 
> suggestions, I would be most grateful ? we?ve just been advertising 
> this service to our new faculty for the year, we?d rather not this be 
> their first experience of it.
> Kelly Phillips
> Archivist ? Digital Programs
> *Special Collections and Archives*
> *Cline Library*
> *Northern Arizona University*
> 928-523-5038
> *** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
> *** Archive: http://www.eprints.org/tech.php/
> *** EPrints community wiki: http://wiki.eprints.org/
> *** EPrints developers Forum: http://forum.eprints.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20180828/693922f2/attachment.html