I’m running n8n in a Docker container on my local machine. I have a workflow that takes file uploads through a webhook and saves them to disk using a binary file writer node. The setup worked fine for months until I tried installing some additional libraries in the container. Now when I trigger the workflow through an API POST request, it never completes and shows “running…” status forever in the n8n interface. The API returns a 500 error. Even though a file gets created in the target folder, it’s corrupted and can’t be opened as an image. The logs show an error about moving files from the temp directory to the final binary data location, but the file does appear in the execution folder. I’m stuck on how to debug this further since rebuilding the container means losing all my custom configurations.
The stuck workflow plus binary corruption screams resource allocation issues, not permissions. Those new libraries you installed probably bumped up memory usage or messed with Docker’s temp file handling. I’ve seen this exact thing happen when containers hit memory limits during binary processing - the workflow just hangs because it can’t finish writing the file properly. Run Docker stats while your workflow’s going and see if you’re maxing out your allocated resources. You’ll probably need to bump up memory limits in your docker-compose file or container run command. Also check if those new libraries are clashing with n8n’s file handling. That 500 error looks like a timeout rather than a clean failure, which backs up the resource constraint idea.
i had a similar issue with n8n when i updated my container too. it seems like the temp files aren’t being handled properly now. have you looked at your docker logs? they might show whats actually going wrong. sometimes those library updates can mess with file movements.
Check your Docker temp directory config after installing those libraries. New libraries often mess with environment variables that control where n8n stores temp binary data during processing. I had the same issue - additional packages overwrote my TMPDIR variable, so n8n wrote temp files to a location that got wiped before the binary writer could access them. That’s exactly what causes your symptoms: files show up but they’re incomplete or corrupted, and workflows just hang forever. Run docker exec -it <container> env | grep -i tmp to see what temp paths you’ve got now vs what they should be. You’ll probably need to explicitly set N8N_BINARY_DATA_TTL and related temp directory variables in your container environment to override whatever those libraries broke.
This looks like a permissions issue that started after you installed those libraries. I ran into the same thing when I messed with my n8n Docker setup and accidentally changed the user context. Files getting created but corrupted means the container can’t properly write to finish the file operations. Check if your new libraries changed the working directory or user permissions inside the container. Back up your n8n data volume first, then try rebuilding. Run docker exec -it <container_name> ls -la on your temp and target directories to compare permissions. Also double-check that your volume mounts didn’t get messed up when you added the libraries. Binary data usually corrupts when the write process gets cut off by permission errors, even though it creates the file initially.