The diagnosis earlier in this thread is correct, and this is indeed a Docker-image fix (the XWiki/XJetty counterpart was already done in XWIKI-21708, 16.4.0).
The No space left on device message is misleading: the embedded Solr suggester (LookupFactory) - and various other libraries - write temporary files directly to java.io.tmpdir, which is not configurable at the Solr level. In a container that default location can be small or tmpfs-backed, so it fills up even when the mapped /usr/local/xwiki/data volume has plenty of free space. That matches the SOLR-10937 pattern.
Fix made in the image: * tomcat/setenv.sh now sets -Djava.io.tmpdir=/usr/local/xwiki/data/tmp, i.e. on the mapped permanent volume, which always has real disk space. It stays overridable through the JAVA_OPTS environment variable. * Because that directory lives on the persistent volume and nothing in the container reaps temporary files (there is no OS tmp-reaper, and the volume survives restarts), xwiki/docker-entrypoint.sh now empties it on every container start, before Tomcat launches. This keeps it from growing without bound and mirrors what XWiki's own Environment does for its xwiki-temp directory.
Workaround on the current image until a new one is published - create the directory once and set the JVM temp dir via JAVA_OPTS, e.g. in docker-compose:
