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

Wed Aug 29 07:30:24 BST 2018

I would disable SELinux temporary to see if it is the guilty. What was 
the fix in 2014?

Il 29/08/2018 00:57, David R Newman ha scritto:
>
> Hi Kelly,
>
> Sorry, I misread your subject line as "upload error on file of ~130k" 
> for some reason.  I do no believe that there would be any restriction 
> prevent files over 130k being uploaded.  The default limit is 1GB.  
> This may still be the tmp directory issue I described previously, as 
> sufficiently small files I suspect will be written directly to the 
> correct place on the filesystem, whereas anything over this size will 
> be transferring the file piecemeal and therefore will collect in the 
> tmp directory and only be moved once the upload is complete.
>
> Regards
>
> David Newman
>
>
> On 28/08/2018 22:52, David R Newman wrote:
>>
>> 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.
>>
>> Regards
>>
>> 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/
>>
>>
>>
>> *** 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/
>
>
>
> *** 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/