Hy,
I’m new to n8n, and I’d like to ask for your help regarding the “Local file Trigger” node.
I haven’t found any recent threads that match my issue, so here goes:
Describe the problem/error/question
I installed n8n on Docker using the AI Starter Kit.
I want to create a RAG using documents stored on my computer. So, I need to start my workflow with this node to retrieve .txt and .pdf files and send them to Docling, then to Qdrant.
Action 1: Add the node with the following settings: Trigger on: “Changes Involving a Specific Folder” / Folder to Watch: /data/shared / Watch for: File Added / Options: Use Poling.
First execution: Node execution > Creation of a Test.txt file in /data/shared > The file appeared in Output = Great, it works
I wanted to try again with another .pdf file:
Delete the Test.txt file > Relaunch the node > Drag and drop the .pdf file into “/data/shared” > It searches, searches, searches, and searches some more without finding anything. ; (Oh no.
I thought maybe it was the PDF (it was only one page) > I repeated the process by creating a new Test.txt file > It doesn’t work anymore either…
I had a Mac mini M4 available > I wanted to try it on that. I installed everything on the computer > I ran it for the first time > It works great. I ran it a second time > It doesn’t find anything either…
Do you know what I’m doing wrong???
my practical advice would be activate the workflow, leave it running, then add a brand-new file into /data/shared and check the execution list instead of restarting the node each time. If it still only fires once after that, then I’d want to see the workflow JSON and the exact Docker volume mapping for /data/shared.
What you’re seeing is usually the difference between a manual test run and the node working as an actual trigger. The first time succeeds because n8n scans the folder state, but after that it normally expects the workflow to stay active and watch for brand-new filesystem events instead of repeatedly re-running the node in the editor.\n\nA few things I’d check:\n1. Activate the workflow, then leave it running, and only after that add a completely new file to /data/shared. Don’t delete/recreate the same file too quickly.\n2. Make sure /data/shared is a real bind mount inside the n8n container, not just a host path you can see from your laptop. In Docker, the path must exist inside the container too.\n3. If you’re on Docker Desktop / Windows or macOS, filesystem events can be flaky through mounted volumes. In that case polling is the right choice, but it may still miss changes if the file is copied atomically or appears before the watcher is fully running.\n4. Try creating a brand-new small .txt file from inside the mounted folder after the workflow is already active, then wait a bit longer than the polling interval.\n\nIf it still only works once, I’d inspect the exact Docker compose volume mapping plus whether the workflow is Active when you test. That usually reveals whether this is a mount issue or just trigger behavior expectations.
Helloooo, thank you so much for trying to help me.
Time doesn’t change anything.
Even if I stop the process in Docker, shut everything down, and restart the computer the next day, it still doesn’t work—just like the first time I ran it, it doesn’t find anything.
Right now, I just started n8n and the node, went to make myself a coffee. Came back, and created a file > nothing happens.
The only way to get it working again (only on the first run) is to uninstall/reinstall everything.
It looks like the first run “burned out the node” (I always run into weird issues that nobody else has ;( ).
For the volume mapping, I assume this is the piece of code from “Docker-compose.yml” that you’re looking for?
The root cause here is that Docker Desktop on macOS and Windows uses a VM-based file-sharing layer (VirtioFS, gRPC-FUSE, or osxfs). Native filesystem events (inotify) from the host don’t propagate reliably into the container — so the Local File Trigger fires once when the workflow activates (initial scan), then never again because it never “sees” new file events.
Two solutions that work:
Switch to Polling Mode
The Local File Trigger node has a polling option. Instead of relying on filesystem events, set it to poll at an interval (e.g., every 60 seconds):
Open the Local File Trigger node settings
Set Trigger On to “Changes to a Specific File” or “Changes to Files in a Specific Folder”
Under Options, look for Poll Times — set a cron expression like * (every minute)
This bypasses the inotify limitation entirely
Use a Schedule Trigger + Read Binary Files
If polling mode still misbehaves, swap the architecture entirely:
Replace Local File Trigger with a Schedule Trigger (e.g., every 5 minutes)
Add an Execute Command node: find /data/shared -newer /tmp/.last_processed -name “.pdf” -o -name “.txt” to find new files since last run
Add a Read Binary Files node to read each file
At the end, add an Execute Command node: touch /tmp/.last_processed to mark the timestamp
This pattern is Docker-proof because it never relies on filesystem events.
Why Mac M4 native also fails
Even on native macOS, the n8n Local File Trigger uses chokidar under the hood, which can miss events depending on the filesystem and polling configuration. The Schedule Trigger approach is the most reliable across all platforms.
Hope this helps! Let me know if you need help setting up either approach.
This sounds less like the node is “burned” and more like the watched folder event is not firing reliably in Docker after the first run. Since you’re using Docker, I’d first test with a file created from inside the container in /data/shared, not by drag-and-drop from the host. If that works, the issue is likely the host-to-container file event propagation, so polling interval / mount behavior is the real thing to check, not the PDF itself.
Hello everyone. It’s working perfectly now. There was indeed a propagation issue. I managed to get everything set up correctly again. Thank you all so much for your help
