After having run flawlessly for a week, publishing stopped working today, and I found the following error in the cd_core log:

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

The path '/tmp/tomcat.3852345956471293540.8082' did not exist on the server, so it was understandable why I should get this error.

Digging further, I found the following line in the same log file:

2016-04-04 16:58:37,248 INFO  LicenseVerifier - catalina.base = 

Of course! The deployer is a microservice which has an embedded version of Tomcat. Apparently the service creates a temporary Cataline base folder in /tmp, and uses that as its Tomcat home.

The problem is now clear: there is a cleanup process on our server which clears the /tmp folder every week. The Catalina base folder has gone, hence publishing fails.

Restarting solves the problem, at least temporarily, because a new temp folder is created. But in a week's time this folder will be removed again.. How to solve this? I could talk to the system maintenance team over here, and tell them to leave my folder alone. But I know what they'll say: anything in /tmp is temporary, you should not expect it to stay around forever.

So (sorry for the long detour) my question is: is there a way to instruct Tridion to use a different Catalina base folder?

  • We recently experienced the same issue and it was due starting an async thread that would handle the multipart file in a Service class. We have two options, hijack the multipart in the controller and then set the bytes in the form bean to send to the service and the other one is upon call of the setMultipartFile, we set the byteStream in the form object that way we keep the controller clean.
    – user2248
    Mar 29, 2017 at 21:52

2 Answers 2


You can add an application.properties file to the config directory of your micro service and in that application.properties file specify the location for the Tomcat folder with the property server.tomcat.basedir:


In the value for the property you can use environmentvariables and Java system properties, e.g.:


Which would create a directory /deployer/tomcat below the users home directory (the user running Tomcat).

Advantage of this approach is that you are not overriding the generic Java temp directory and that the embedded Tomcat is always using the same work directory (and not a different one after each restart).

  • That looks great. I will try it out and let you know if it works. Is this documented anywhere by the way?
    – Quirijn
    Aug 31, 2016 at 11:57
  • I don't know if adding (or editing) the application.properties file is documented in the SDL Web 8 documentation. The micro services are based on Spring boot, and configuring the embedded Tomcat is described in the Spring boot docs (e.g. at docs.spring.io/spring-boot/docs/current/reference/html/…). Sep 1, 2016 at 12:50
  • I tried this way. It seemingly didn't work well. But the "-Djava.io.tmpdir" worked.
    – X.Chen
    Mar 28, 2017 at 8:40
  • Updated the config and restarted the service its works awesome
    – Velmurugan
    Sep 14, 2017 at 21:59

Okay, found it. You can specify override the /tmp folder by modifying the start.sh script:

JVM_OPTIONS="-Xrs -Xms256m -Xmx512m -Djava.io.tmpdir=/opt/tridion/deployer-live/tmp"

The first three options (-Xrs -Xms256m -Xmx512m) are out of the box, I just added '-Djava.io.tmpdir=/opt/tridion/deployer-live/tmp'.

The tomcat home folder and docbase folder are now created in the location that I specified, and the cleanup script can no longer do any harm.

  • Awesome. Works fine. Jan 17, 2019 at 11:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.