Persistent “upload failed” error in DSpace 7/8 – troubleshooting steps and request for guidance

[Gladys Vanesa Fernandez]

Hello DSpace technical community,

I am managing a DSpace 7/8 installation and have been encountering a recurring problem whenever users try to upload PDFs. The interface always returns a “upload failed” message. After numerous attempts to diagnose and fix this issue, I’m reaching out for your guidance. Below is a summary of the troubleshooting steps I’ve performed:

1. **Assetstore regeneration** – On version 7, I tried deleting the `/dspace/assetstore` directory and regenerating it. Interestingly, this fix worked for about a day, but then the “upload failed” error returned.
2. **Permissions and ownership** – I confirmed the permissions and ownership of `/dspace` and all subdirectories (including the assetstore). The Tomcat user owns these directories, and file system permissions are open enough to allow writing. Running manual tests (e.g., writing files to the assetstore as the Tomcat user) works without issue.
3. **Config checks** – I verified that `assetstore.dir` and other relevant paths in `dspace.cfg`/`local.cfg` point to the correct locations. I have also ensured that there is sufficient disk space and no file system quotas preventing uploads.
4. **Review of logs** – I examined the DSpace logs (`dspace.log`) and Tomcat logs. The messages show an error whenever files are stored, but there is no obvious stack trace pointing to permission issues. The error message is similar to: “Failed to upload file; upload failed.”
5. **System-level investigation** – I looked into whether the problem could be related to the service configuration. Some documentation suggests that Tomcat’s systemd unit may be sandboxed and unable to write to the assetstore directory unless configured with `ReadWritePaths=/dspace`. I haven’t yet edited the systemd unit file, as I’m seeking confirmation that this is the right direction.

At this stage, I’m uncertain what is causing the upload failures. I would appreciate any suggestions on further diagnostic steps or specific configuration changes to resolve this problem permanently.

Thank you in advance for your time and expertise.

Best regards, Gladys

[Andrew K]

Gladys Vanesa Fernandez:

5. **System-level investigation** – I looked into whether the problem could be related to the service configuration. Some documentation suggests that Tomcat’s systemd unit may be sandboxed and unable to write to the assetstore directory unless configured with `ReadWritePaths=/dspace`. I haven’t yet edited the systemd unit file, as I’m seeking confirmation that this is the right direction.

This is most probably the reason. Try that solution first.

Best regards,

Andrew

 

[Shaun donovan]

Hi Gladys.

I doubt if number 5 is your problem, as it would not have "worked for a while" if that was the case. The only thing that comes to my mind is ensuring that disableUploadTimeout="true" on the Tomcat connector is set.

Good Luck

Shaun

--
All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
---
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dspace-tech/4757fe3c-7469-4f88-b4d4-5f0982a25feen%40googlegroups.com.

[Gladys Vanesa Fernandez]

Hello everyone,

Thank you for the suggestions and guidance you’ve shared regarding the upload failures in our DSpace 7/8 instance. I wanted to provide an update on what we’ve tried and the current state of the issue.

We run DSpace behind the same reverse proxy we use for Moodle, so file uploads are generally handled without special restrictions. I also added the recommended ReadWritePaths setting to the Tomcat systemd unit and increased Spring Boot’s upload size limits in local.cfg. After restarting the services, uploads improved: some files are stored correctly and appear in the logs as new bitstreams attached to items.

Unfortunately the problem hasn’t entirely disappeared. The behaviour is inconsistent: sometimes a PDF uploads without issue, other times the progress bar stays at 0 % and the interface reports “upload failed” even though the server logs show that the file was saved. We have ruled out excessively large files (we’re testing with relatively small PDFs) and the reverse proxy does not seem to be limiting us.

If anyone has additional ideas on what could cause this intermittent “upload failed” message, or things we might check next, I’d be grateful. Thank you again for your help so far.

Best regards,

[DSpace Technical Support]

Hi,

You may want to look more closely for errors occurring when the upload process fails.  Those errors would either be in the UI layer or in the logs on the backend.  We have a troubleshooting guide which tries to guide you through finding detailed error messages: https://wiki.lyrasis.org/display/DSPACE/Troubleshoot+an+error#Troubleshootanerror-DSpace7.x(orabove)

If you can find a detailed error message, then it may tell you exactly what the problem is.  But, this would require finding a way to replicate the issue and checking for whether a detailed error message can be found.

A few other tips: when looking at the logs, keep an eye for the "Caused By" part of the stacktrace (or several of them), as they tend to tell you more information about what is going on. Also, check to see if there are earlier errors reported in the logs *before* the final upload error. Sometimes an earlier error can "snowball" into later problems.

Tim

[Agustina Martinez-Garcia]

Hi Gladys,

Apologies if obvious but have you checked that the following config property is set and the directory exists: https://wiki.lyrasis.org/display/DSDOC7x/Configuration+Reference#ConfigurationReference-UploadFileSettings ?

We have found this one in the past to cause issues at least for SWORD file uploads and AIP packages creation, although I am not sure is also used for UI uploads. Just in case it helps!

Best,

Agustina