The temporary upload location [/tmp/tomcat.4296537502689403143.5000/work/Tomcat/localhost/ROOT] is not valid

▼魔方 西西 提交于 2019-12-02 22:26:23
  1. The http POST methods will use these temp location to store the post data.
  2. Some OS 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 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

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.

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

Edwin Lambregts

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:

  1. Stop the application
  2. Stop Zuul
  3. Remove tomcat related folders in the /tmp folder (this is where our tomcat folders were stored, might be different for others)
  4. Restart Zuul
  5. 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.

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.

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

user3450862

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.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!