A complete troubleshooting guide for fixing file write & binary data issues on Windows + Docker + WSL
Introduction
If you run n8n locally using Docker on Windows, sooner or later you may face one of these problems:
-
Workflows fail when saving files -
Binary data nodes throw permission denied -
Files appear inside the container but not on Windows -
/home/node/fileslooks empty -
n8n cannot write PDFs, images, or downloads
This tutorial is a practical, community-driven debugging method developed after helping multiple users solve the same issue.
Instead of random fixes, we follow a structured layer-by-layer diagnostic approach that usually resolves the issue in under 2 minutes.
Important: This Guide Has Branching Paths
Not all setups fail for the same reason.
Depending on what result you see, you may jump to different sections.
Follow the steps in order and move to the section indicated by your result.
1. Understanding the Real Problem (The 4 Layers)
File-system issues happen because Docker setups on Windows involve multiple environments:
| Layer | What it controls |
|---|---|
| 1. Windows Host | Real folder existence |
| 2. WSL Mount | Linux access to Windows drives |
| 3. Docker Mount | Folder mapped into container |
| 4. n8n Runtime | Permissions & binary storage config |
We debug top - down.
Fixing an upper layer usually fixes everything below it.
2. The 2-Minute Debug Checklist (Start Here)
Open PowerShell:
docker ps
Confirm your n8n container is running.
Step 2 ā Test writing inside container
docker exec -it n8n sh
(Modern n8n images use sh, not bash.)
Inside container:
touch /home/node/files/test.txt
ls -l /home/node/files
If test.txt appears
Your filesystem works correctly.
If you see permission errors
Go to Section 5 (Permissions Fix).
If folder is empty or missing
Go to Section 4 (Docker Mount Fix).
3. Correct n8n Docker Configuration (Reference Setup)
A working example:
docker run -d --name n8n -p 5678:5678 `
-v n8n_data:/home/node/.n8n `
-v C:\n8n_files:/home/node/files `
-e N8N_BINARY_DATA_MODE=filesystem `
-e N8N_BINARY_DATA_STORAGE_PATH=/home/node/files `
n8nio/n8n
4. Docker Mount Problems (Most Common Cause)
Check mounts
Run:
docker inspect n8n --format '{{json .Mounts}}'
You should see something like:
Source: C:\n8n_files
Destination: /home/node/files
If mount is missing
Your container was started incorrectly.
Fix
docker stop n8n
docker rm n8n
Recreate using the command in Section 3.
Verify host folder exists
mkdir C:\n8n_files
dir C:\n8n_files
Docker cannot mount folders that do not exist.
5. Permission Denied Fix (WSL Solution)
If touch failed inside container:
Permission denied
This means Windows ownership does not match the container user.
n8n runs as:
UID 1000 (user: node)
Open WSL (Ubuntu)
wsl -d Ubuntu
Then run:
sudo chown -R 1000:1000 /mnt/c/n8n_files
sudo chmod -R 775 /mnt/c/n8n_files
For debugging only:
sudo chmod -R 777 /mnt/c/n8n_files
Restart container:
docker restart n8n
Test again (Section 2).
6. Common Mistakes (Seen Repeatedly)
Using bash instead of sh
Error:
bash: executable file not found
Fix:
docker exec -it n8n sh
Running commands inside docker-desktop WSL
Symptoms:
-
no
/mnt/c -
sudo missing
Check distributions:
wsl -l -v
Use a real distro like Ubuntu.
Running docker compose down anywhere
You must be inside the folder containing:
docker-compose.yml
Otherwise:
no configuration file provided
7. Final Verification (The Success Test)
Inside container:
touch /home/node/files/test.txt
Now check Windows:
C:\n8n_files
If the file appears - Fully fixed. ![]()
n8n can now safely store binary data.
8. Performance Tip (Advanced Users)
Windows bind mounts are slower.
For heavy AI or PDF workflows:
Use WSL-native storage:
/home/username/n8n_files
Mount instead:
-v /home/username/n8n_files:/home/node/files
This can be 3ā10Ć faster for large workflows.
9. Quick Command Reference
Enter container
docker exec -it n8n sh
Inspect mounts
docker inspect n8n --format '{{json .Mounts}}'
Fix permissions
sudo chown -R 1000:1000 /mnt/c/n8n_files
Restart
docker restart n8n
10. Conclusion
File-system errors in Dockerized n8n are rarely caused by n8n itself.
They almost always come from:
-
missing bind mounts
-
incorrect folder ownership
-
WSL environment confusion
-
incorrect binary storage configuration
Once permissions and mounts align, n8nās filesystem mode becomes extremely reliable.
11. Community Feedback (Important
)
This guide was built from real troubleshooting sessions.
During the first month after publishing, please share:
-
Your OS + Docker Desktop version
-
Your exact error message
-
Which step solved your problem
-
Any edge cases not covered
I will update and refine this tutorial based on community feedback so future users can fix issues faster.
