n8n automation gets stuck during execution and creates broken files

I’m running n8n in a Docker container on my local machine and having issues with a workflow that was working fine before. The workflow is pretty basic - it has a webhook that receives POST requests and then uses a file writer node to save uploaded images to a folder that’s mapped from the container to my host system.

Everything was working great until I tried installing some image processing tools in the container. Now when I trigger the workflow through the API, it never finishes and just hangs forever. The API returns a 500 error and the n8n dashboard shows the execution as permanently “running”.

The weird part is that files do get created in the target directory and they’re about the right size, but they’re completely corrupted and won’t open as images. Looking at the n8n logs, I can see an error about moving files from a temp location to the final binary data folder, but the execution folder does exist with the file in it.

I’ve tried everything I can think of and searched online but can’t figure out what’s causing this. Has anyone seen similar issues with n8n file operations getting stuck? The logs show the workflow nodes completing successfully but then failing during some cleanup process.

{
  "name": "image-upload-handler",
  "nodes": [
    {
      "parameters": {},
      "name": "Trigger",
      "type": "n8n-nodes-base.start",
      "typeVersion": 1,
      "position": [250, 400],
      "id": "starter-node-id"
    },
    {
      "parameters": {
        "fileName": "=/uploads/photos/{{ $json.query.imagename }}.png",
        "dataPropertyName": "=filedata",
        "options": {}
      },
      "name": "Save File",
      "type": "n8n-nodes-base.writeBinaryFile",
      "typeVersion": 1,
      "position": [800, 400],
      "id": "file-writer-node"
    },
    {
      "parameters": {
        "authentication": "headerAuth",
        "httpMethod": "POST",
        "path": "photo-upload-endpoint",
        "responseMode": "lastNode",
        "options": {}
      },
      "name": "API Endpoint",
      "type": "n8n-nodes-base.webhook",
      "typeVersion": 1,
      "position": [500, 400],
      "webhookId": "webhook-unique-id",
      "id": "api-receiver-node"
    }
  ],
  "connections": {
    "API Endpoint": {
      "main": [[
        {
          "node": "Save File",
          "type": "main",
          "index": 0
        }
      ]]
    }
  },
  "active": true
}

I’ve encountered this exact behavior before and it’s usually related to the binary data handling in n8n getting corrupted. The fact that your files are being created but are corrupted suggests the writeBinaryFile node is partially working but the data stream is getting interrupted. Try adding explicit encoding parameters to your writeBinaryFile node and check if your container has sufficient memory allocated. When I had similar issues, increasing the Docker memory limit to at least 2GB resolved the hanging executions. Also worth checking if your image processing tools installation left any orphaned processes that might be interfering with file operations - I had to clean restart my container after removing conflicting dependencies.

Check your container’s disk space and temporary directory cleanup settings. I ran into something very similar where the n8n container was running out of space in its temporary execution folder, causing the file operations to complete partially but fail during the final move operation. The corrupted files you’re seeing are likely incomplete writes that get cut off when the temp space fills up. After installing image processing tools, your container probably has less available space and different cleanup behaviors. Try mounting a larger volume for n8n’s data directory or cleaning out old execution data manually. You can also add explicit temp directory configuration in your n8n environment variables to point to a location with more space.

sounds like a docker volume permission issue to me. when you installed those image tools did you change the user context? try checking if the n8n process still has write access to your mapped folder, sometimes package installs mess with file permissions and cause exactly this kind of hanging behavior