N8n not running in the background (onprem)

Describe the problem/error/question

Hello,
Ever since the upgrade to 2.0 my workflow is not able to run in the background. It had no issues before the update. It’s a quite long workflow, gets some data, some images, combines them, posts on X (twitter), one AI node.
If I press execute workflow there are no issues, it runs fine, around 45s. But in the background it stops after around 1s. I seems like it fetches the images but stops at the merge node.
Anyone faced the same issue?
AI was no help.

Information on your n8n setup

  • n8n version: 2.X
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app): Docker
  • Operating system: Linux

Hi @helvetic_H Set your Merge node’s “Combine Mode” to “Wait for all inputs” to resolve the background execution issue after the 2.0 update

Hi @Anshul_Namdev

Thanks for you quick answer.
I’m seeing this option. Am I missing something:


BR
HH

1 Like

@helvetic_H you can use the ‘Combine’ and attach your flow branches and it should work, let me know if it helps.

hi @Anshul_Namdev
Yes, that’s what I’m using:

Or do you mean something else?
I’m not seeing an option for waiting

BR

Ah @helvetic_H just give it a run! it would not merge everything and pass forward until all the branches are executed! Cheers!

Ho maybe I didn’t explain well. This is not a change that I did. This is the state where I have the issue. Running it with the UI open and looking at it works fine. It’s when running in the background that the issue appear.

Um so the merge node gives issues when working live in background, have you tried code node to merge all the flow branches and then manually output when merged?

Thanks, so I tired this, and now it seems like I had misidentified the issue…

The node Read/Write Files from Disk is not outputting anything… “Always output data” is not an option.
I don’t know how to debug as when I’m executing manually there is no issues… Did this node change with 2.0?
BR

@helvetic_H

Let’s do this validation to see if it works. Please follow these steps.

Steps

1 – Validate the path explicitly

Before the Read/Write Files from Disk node, add a Code node (or an IF node) with the following code:

return [{
  json: {
    path: $json.path,
    exists: require('fs').existsSync($json.path),
  }
}]

This confirms whether the file actually exists during background execution.
If exists returns false, the Read/Write Files from Disk node will not output any data, which is expected behavior in n8n.


2 – Use absolute paths (mandatory when running in Docker)

Avoid relative paths like:

./images/file.png

Use absolute paths instead:

/files/images/file.png

And make sure your docker-compose.yml includes a proper volume mount:

volumes:
  - ./files:/files

3 – Confirm file permissions inside the container

Exec into the container and check the directory permissions:

ls -lah /files

The files must be readable by the user running n8n inside the container.


4 – Add explicit logging (best practice)

Before and after the Read/Write Files from Disk node:

  • add a Set node or a Code node
  • log the following values:
    • file path
    • expected file size
    • timestamp
      This makes it much easier to distinguish between “no data reached the node” and “the node executed but produced no output”.

If needed, the next steps would be validating that the path is absolute, confirming that the Docker volume is correctly mounted, or adjusting the workflow to avoid filesystem dependency (for example, working with in-memory binaries).

Let us know if works

Hi Tamy,
The code didn’t work, but I replaced it with only this:
return [{}];
And it kinda fixed it… I’ll have to test in prod, but it already looks better.

The other steps I did as suggested, everything looks fine. I’ll let you know.
BR

2 Likes

Hi all,

Thanks for helping. According to AI:
In n8n 2.x, nodes only execute per incoming item; if a node receives zero items, it does not run and produces no output. Manual executions inject a temporary item for convenience, but background executions do not, so file nodes require an explicit “starter” item (for example via a Code or Trigger node) to run.

Not sure if it’s intended so, but at least it’s a workaround for now