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, El lunes, 1 de septiembre de 2025 a las 10:36:56 UTC-3, Gladys Vanesa Fernandez escribió: > 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 > -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/dspace-tech/aceca432-25d6-4ad4-880f-8453b70576b6n%40googlegroups.com.
