I am using Spring Boot 1.5.13 version.
I got the exception message like below.
Could not parse multipart servlet request; nested exception is java.io.IOException: The temporary upload location [/tmp/tomcat.4296537502689403143.5000/work/Tomcat/localhost/ROOT] is not valid
I founded out this issue in Spring Github Issues.
https://github.com/spring-projects/spring-boot/issues/9616
But I still have questions of that.
- I am not using File Upload things in my app. But the log says that "Could not parse multipart servlet request" why is that? (I got the exception when my app uses RestTemplate (Post method)
- To solve the exception, I rebooted my app but It did not work right away. Although i rebooted my app, it had referenced the tomcat directory which was not exist. After a day after rebooting, it worked. I guess the directory was cached in somewhere in Spring or else..?
Please Help me out!
- The http POST methods will use these temp locations to store the post data.
- Some OSs like centOS will delete the temp dir frequently. So, even you set that location's permission, after some time that dir will be removed by the OS. And after you reboot, the temp dir will be different.
You can set the multipart location in application.yml:
spring:
http:
multipart:
location: /data/upload_tmp
Update
As per comment by Vivek Sethi above property didn't work for me but the below one.
spring.servlet.multipart.location=/data/upload_tmp
Just restart your application in the server. It is a bug between spring and tomcat servers. Once the application restarts it consume a temp directory in the server.
We've had this problem since long too, I just wanted to eloborate some stuff relating to 2) in above accepted answer.
So, the problem here is that tomcat's temp folders suddenly "disappears" and not for "POSTs in general" as is claimed but for multipart requests specifically. Thus
spring.servlet.multipart.location/spring.http.multipart.location
is involved here. As @Frankstar said above, in recent spring-boot code this is fixed by "always creating the tmp-folder if it's not there", works too of course if you're running a super-fresh spring-boot.
You can, as suggested as in the accepted answer, point it to somewhere else other than /tmp and it will work fine (though, regarding cleanup you should perhaps have a read here https://github.com/spring-projects/spring-boot/issues/9983 - you are now reliant on spring-boots cleanup which, though, should work fine).
But why did the folder actually disappear? Further down @Hasan Sawan says that "It is a bug between spring and tomcat servers". But is it really..?
For us the solution was to configure this stuff. OSes such as CentOS will use (see for instance https://www.thegeekdiary.com/centos-rhel-7-how-tmpfiles-clean-up-tmp-or-var-tmp-replacement-of-tmpwatch)) systemd for cleaning up /tmp - and anything not accessed within 10 days will be cleaned by the default setting.
Thus on our redhat servers we solved this be editing
/usr/lib/tmpfiles.d/tmp.conf
adding a line like
X /tmp/tomcat.*
to solve this issue. You can verify this too using
# SYSTEMD_LOG_TARGET=console SYSTEMD_LOG_LEVEL=debug /usr/bin/systemd-tmpfiles --clean 2>&1 | grep tomcat
where you will see that these directories will now be ignored.
There is also this fix for systems whereas tmpwatch is used instead https://javahotfix.blogspot.com/2019/03/spring-boot-micro-services-tmptomcat.html
Note : the solutions mentioned above to "restart" or to just # mkdir /tmp/tomcat.... were simply not accepted where I work.
This Issue was fixed a couple of days ago.
Spring Boot: 2.1.4 or 1.5.20
This version bump fixes an issue when the tmp dir was deleted
by the OS and the spring boot app tries to handle a multifile
upload.
Issue: https://github.com/spring-projects/spring-boot/issues/9616
https://github.com/MeiSign/Copy-Pasta/commit/1200fb353a48a3d0c92038dee7cced7cebf3acfe
Question has already been answered, but maybe I can help someone out. I had this problem as well, but none of the suggested solutions worked for me.
We use Spring boot in combination with Zuul, which boiled down to the following:
- Stop the application
- Stop Zuul
- Remove tomcat related folders in the /tmp folder (this is where our tomcat folders were stored, might be different for others)
- Restart Zuul
- Restart the application
Simply restarting the application did not work for us, as it was pointing to a non-existing folder: the name was cached somewhere.
When using Zuul, the request go through Zuul first and throw exception there.
In micro services architecture, problem can be due to Zuul timeout. I faced the same issue and tried everything above discussed but did not work. After I increased timeout with dfs-bulk-service.ribbon.ReadTimeout=90000 configuartion in Zuul properties, it worked fine. Here dfs-bulk-service is my micro service name configured with Zuul as api gateway.
You maybe encode the form body of the POST request by Content-Type: multipart/form-data
http header .
You should send a Content-Type: application/x-www-form-urlencoded POST
What I did to solve the issue was to relaunch the application adding -java.tmp.dir=/path/to/application/temp/
and creating a /temp/
folder in my application folder.
For me it was using the correct dependency (if using java/maven)
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>2.6</version>
</dependency>
It is recommended to specify custom directory path for temp storage through spring (or server) configuration.
But quick hack would be to create the mentioned directory and provide the read/write permissions as
mkdir -p /tmp/tomcat.4296537502689403143.5000/work/Tomcat/localhost/ROOT
chmod 755 /tmp/tomcat.4296537502689403143.5000/work/Tomcat/localhost/ROOT
tomcat.xxxxxxxxxxxx.xxxx - This will be different on each server.
Use this directory name from your server error.