Временное расположение загрузки [/tmp/tomcat.4296537502689403143.5000/work/Tomcat/localhost/ROOT] недействительно

1. Методы http POST будут использовать эти временные местоположения для хранения данных публикации.
2. Некоторые ОС, такие как CentOS, часто удаляют временный каталог. Таким образом, даже если вы установили разрешение для этого местоположения, через некоторое время этот каталог будет удален ОС. И после перезагрузки временный каталог будет другим.

Вы можете установить расположение нескольких частей в application.yml:

spring:
  http:
    multipart:
      location: /data/upload_tmp

Обновлять

Согласно комментарию Вивека Сетхи, вышеупомянутое свойство не сработало для меня, а вот свойство ниже.

spring.servlet.multipart.location=/data/upload_tmp

Для решения проблемы я перезапустил приложение, добавив -java.tmp.dir=/path/to/application/temp/ и создав папку /temp/ в папке моего приложения.

Просто перезапустите ваше приложение на сервере. Это ошибка между серверами Spring и Tomcat. После перезапуска приложения оно использует временный каталог на сервере.

На вопрос уже был дан ответ, но, возможно, я смогу кому-то помочь. У меня тоже была эта проблема, но ни одно из предложенных решений не помогло мне.

Мы используем Spring boot в сочетании с Zuul, что сводится к следующему:

1. Остановить приложение
2. Остановить Зуула
3. Удалите папки, связанные с tomcat, в папке / tmp (здесь хранились наши папки tomcat, для других может быть иначе)
4. Перезапустить Зуул
5. Перезапустите приложение

Просто перезапустить приложение у нас не получилось, так как оно указывало на несуществующую папку: имя где-то кешировалось.

При использовании Zuul запрос сначала проходит через Zuul и генерирует исключение.

В архитектуре микросервисов проблема может быть связана с тайм-аутом Zuul. Я столкнулся с той же проблемой и попробовал все, что обсуждалось выше, но не сработало. После того, как я увеличил время ожидания с помощью конфигурации dfs-bulk-service.ribbon.ReadTimeout = 90000 в свойствах Zuul, все заработало. Здесь dfs-bulk-service - это мое имя микросервиса, настроенное с Zuul в качестве шлюза api.

Эта проблема была исправлена ​​пару дней назад. Spring Boot: 2.1.4 или 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.

Проблема: https://github.com/spring-projects/spring-boot/issues/9616

https://github.com/MeiSign/Copy-Pasta/commit/1200fb353a48a3d0c92038dee7cced7cebf3acfe

У нас тоже была эта проблема давно, я просто хотел рассказать о некоторых вещах, касающихся 2) в принятом выше ответе.

Итак, проблема здесь в том, что временные папки tomcat внезапно «исчезают», причем не для «POST вообще», как утверждается, а конкретно для многостраничных запросов. Таким образом

spring.servlet.multipart.location / spring.http.multipart.location

здесь участвует. Как сказал @Frankstar выше, в недавнем коде весенней загрузки это исправлено «всегда создавая tmp-папку, если ее нет», тоже работает, конечно если вы используете супер-свежую весеннюю загрузку.

Вы можете, как предложено в принятом ответе, указать его где-нибудь еще, кроме / tmp, и он будет работать нормально (хотя, что касается очистки, вам, возможно, следует прочитать здесь https://github.com/spring-projects/spring-boot/issues/9983 - теперь вы полагаетесь на очистку весенних ботинок, которая, правда, должен работает нормально).

Но почему папка на самом деле исчезла? Далее @Hasan Sawan говорит, что «это ошибка между серверами Spring и Tomcat». Но так ли это на самом деле?

Для нас решение состояло в том, чтобы настроить этот материал. Операционные системы, такие как CentOS, будут использовать (см., Например, https://www.thegeekdiary.com/centos-rhel-7-how-tmpfiles-clean-up-tmp-or-var-tmp-replacement-of-tmpwatch)) systemd для очистки / tmp - и что-нибудь, к которому не было доступа в течение 10 дней, будет очищен по умолчанию.

Таким образом, на наших серверах redhat мы решили, что это редактирование

/usr/lib/tmpfiles.d/tmp.conf

добавив строку вроде

X /tmp/tomcat.* 

чтобы решить эту проблему. Вы также можете проверить это, используя

# SYSTEMD_LOG_TARGET=console SYSTEMD_LOG_LEVEL=debug /usr/bin/systemd-tmpfiles --clean 2>&1 | grep tomcat 

где вы увидите, что эти каталоги теперь будут игнорироваться.

Также есть это исправление для систем, тогда как tmpwatch используется вместо https://javahotfix.blogspot.com/2019/03/spring-boot-micro-services-tmptomcat.html

Примечание: упомянутые выше решения для "перезапуска" или просто # mkdir / tmp / tomcat .... были просто не приняты там, где я работаю.

Возможно, вы закодируете тело формы запроса POST с помощью Тип содержимого: multipart / form-data HTTP-заголовок.

Вы должны отправить Тип содержимого: application / x-www-form-urlencoded POST

Для меня использовалась правильная зависимость (при использовании java / maven)

       <dependency>
            <groupId>commons-io</groupId>
            <artifactId>commons-io</artifactId>
            <version>2.6</version>
        </dependency>

проверьте папку в C: /, если нет одной папки с именем темп, чем создайте ее C: / temp``, это решение сработало для меня