Место временной загрузки [/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

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

Эта проблема была исправлена ​​пару дней назад.
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 — теперь вы полагаетесь на spring-boots очистки, которая, тем не менее, должна работать нормально).

Но почему папка на самом деле исчезла? Далее @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.... просто не принимались там, где я работаю.

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

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

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

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

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

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

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

Вы можете закодировать тело формы запроса POST с помощью Content-Type: multipart/form-data http-заголовка.

Вы должны отправить Content-Type: application/x-www-form-urlencoded POST

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

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

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