Replies: 4 comments 3 replies
-
|
Hi @Alceatraz! I'm Dosu and I’m helping the Stirling-PDF team. The "Setting permissions and ownership for necessary directories" step is handled by the Docker entrypoint scripts before the Java app starts. It uses commands like To resolve this, check that all mounted directories exist and are writable by the container user. You can try removing or replacing hostPath volumes with empty directories to isolate the issue. Avoid mapping host directories to Stirling PDF can run fully offline if all required assets (fonts, Tesseract data, binaries) are present in the image or mounted volumes. The default image may try to install font packages from Alpine repositories at startup, which requires network access unless these packages are already present. Using the To reply, just mention @dosu. How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other |
Beta Was this translation helpful? Give feedback.
-
|
I check the permission Then I retry with this command to avoid any host permission issue Still stuck Then I found Any how to verbose this process? |
Beta Was this translation helpful? Give feedback.
-
|
The hang at "Setting permissions and ownership for necessary directories" is almost always caused by missing or unwritable temp directories inside the container. Stirling-PDF expects You can fix this by manually creating mkdir -p /usr/tmp && chown stirlingpdfuser:stirlingpdfgroup /usr/tmpOr, exec into the container and run it interactively. Avoid mounting host directories to There is no built-in way to increase verbosity for this shell-script step; only minimal Once all temp directories exist and are writable, the container should proceed past the permissions step and start normally. To reply, just mention @dosu. How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
The most common cause for the Java process hanging at this step is a permissions or ownership issue with the temp directory, especially /tmp or /tmp/stirling-pdf. Even if the directory exists, if the container user (often stirlingpdfuser) cannot write to it, Java will hang or fail to start. This is often seen with NFS or network mounts, or if the directory is owned by root or another user. The fix is to create a tmp directory on the host, set its ownership to the container user UID (usually 1000), chmod 755, and mount it into the container at /tmp. This has resolved similar hangs for others—see the detailed steps and discussion here. To debug further, you can:
You can also increase Java/Spring Boot log verbosity by setting logging.level.stirling.software.SPDF: DEBUG in /configs/custom_settings.yml (see docs), but if the process hangs before logging starts, the issue is almost always a filesystem or native dependency problem. If you try these steps and still get stuck, check the permissions and ownership of /tmp and /tmp/stirling-pdf inside the container, and try mounting a known-good tmp directory from the host as described above. To reply, just mention @dosu. How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other |
Beta Was this translation helpful? Give feedback.
-
|
I also try to manual install. Follow the guide But event with venv, start the unoserver All package installed: |
Beta Was this translation helpful? Give feedback.
-
|
The error happens because unoserver needs the uno Python bindings that come with LibreOffice, not the uno package from PyPI. Installing uno via pip does not work—unoserver must run in the same Python environment as LibreOffice, where the real uno module is available. On Debian 12 and similar systems, this is especially problematic: the python3-uno package is not compatible with Python 3.11, and the LibreOffice Python runtime is missing, so unoserver cannot function in a standard venv or with system Python. This results in the "No module named 'base'" and "Could not find the 'uno' library" errors you see [details]. The simplest fix is to use the official unoserver Docker container, which bundles LibreOffice, Python, and the correct UNO bindings. If you need a manual install, you must ensure that the Python interpreter running unoserver is the one bundled with LibreOffice (usually found in /usr/lib/libreoffice/program/python), and that the uno module from LibreOffice is available in your PYTHONPATH. On Debian 11 or Ubuntu 22.04, installing libreoffice and python3-uno from apt is usually sufficient, but on Debian 12 this is broken by design [reference]. Manual workarounds like building LibreOffice from source or downgrading Python are not recommended—they are complex and error-prone. If you must run unoserver outside Docker, use an OS version with compatible LibreOffice packaging, or copy the uno and unohelper modules from LibreOffice into your venv and set PYTHONPATH accordingly, but this is fragile and not officially supported [reference]. In summary: pip-installed uno is not sufficient; unoserver must run with LibreOffice's Python and UNO bindings. For Debian 12 and similar, use the unoserver Docker container or switch to a compatible OS. To reply, just mention @dosu. How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
The boot process stuck here and
stirling.software.SPDF: DEBUGnot showing more logs. (I was waiting for it about 2 hours, For chmod that's long enought I think.)What is that process doing ? How to solve this ?
And is there any way to run stirling out of box (without any networking/download)?
Beta Was this translation helpful? Give feedback.
All reactions