Hi everyone,
I’m running a self-hosted n8n instance on a Hostinger VPS and since a recent update, all workflows that process PDFs/documents have stopped working.
Environment
n8n version: 2.16.1 (Self Hosted)
Deployment: Docker / Docker Compose
Binary data mode: filesystem
VPS: Hostinger Ubuntu 24.04 with n8n template
VPS ID: 990575
Hostname: srv990575.hstgr.cloud
Public IPv4: 31.97.199.227
n8n URL: https://api.novaintellectagents.com
Problem
The failure happens in the node:
Node: Extract from File
Operation: pdf
Exact error:
Invalid PDF structure.
What changed
Everything worked fine about 1 week ago
I did not manually change the workflows
The issue now affects all document-related workflows
It seems to have started after the n8n container was recreated/updated recently
What I suspect
This may be related to:
a regression in PDF handling,
a change in binary file processing,
binaryDataMode=filesystem,
or a breaking change introduced in a recent n8n update.
What I need help with
Has anyone seen this issue before?
Is this a known regression?
Is there a recommended workaround?
Should I pin n8n to a specific version?
Is there anything I should check in the workflow or Docker config?
If useful, I can share logs, workflow screenshots, or a sample file.
Thanks in advance.
Describe the problem/error/question
What is the error message (if any)?
Please share your workflow
(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)
Hey Rafael, that Invalid PDF structure error after a recent update usually points to a breaking change in how n8n handles binary file metadata — especially with binaryDataMode=filesystem. Since you’re on 2.16.1, try these diagnostics: (1) Check n8n logs for any binary serialization errors around PDF loading (2) Test with a fresh minimal PDF in a new Extract from File node — if it works, the issue is workflow-specific metadata corruption (3) If all PDFs fail: revert to the prior n8n version temporarily to confirm it’s a regression. If it’s truly a regression post-update, the n8n team should know — worth checking GitHub issues (might already be reported). In the meantime, pinning to the last working version is a solid workaround. What n8n version were you on before the update?
@Rafael_Van_Meerbeek your container got recreated and almost certainly wiped the filesystem binary store — n8n still holds stale references to files that no longer exist on disk, so every PDF reads as corrupt. check your docker-compose volumes: block maps /home/node/.n8n to a persistent host path. run this against a fresh PDF to confirm extraction itself is fine:
if that extracts fine, your n8n install is good and it’s just orphaned binary refs from the old container — re-trigger the source workflows so they fetch fresh files.
welcome to the n8n commuity @Rafael_Van_Meerbeek
I’d also try downloading the exact binary file right before the Extract from File node and opening it locally. That helps confirm whether the node is receiving a real PDF or an HTML/error response saved as a .pdf. Sometimes an upstream HTTP/download node returns a login page, 403/404 page, or empty response, and the PDF extractor then reports “Invalid PDF structure” even though the real issue started earlier in the workflow.