Read/Write Files from Disk node throwing "is not writable" on multiple environments (Windows & Docker) - v2.26.4

Describe the problem/error/question

Hi everyone,
I’m facing a persistent issue with the Read/Write Files from Disk node (v1.1) when trying to execute a “Write File to Disk” operation. It consistently throws an error stating that the file is not writable, regardless of the folder, user permissions, or execution mode.

My Environment:

  • n8n Version: 2.26.4 (Self Hosted)
  • Execution Mode: Tested both on native Windows (Node.js setup) and via Docker Desktop (WSL2 backend).
  • Database Mode: Tested with both binaryDataMode: filesystem and binaryDataMode: database.

What I’ve tried so far:

  1. Native Windows: Targeted local folders (C:\n8n\poema.json) and temporary paths. Got the “not writable” error.
  2. Docker (Standard User): Mounted volume -v c:/n8n:/data and targeted /data/poema.json. Fails.
  3. Docker Isolated Path: Tried writing directly into Docker container native paths like /tmp/poema.json and /home/node/poema.json. Fails with the exact same error.
  4. Pre-creating the file: I manually created an empty poema.json file (0 KB) inside the destination folder to check if it was a creation vs update issue. Still throws “not writable”.
  5. Docker Root User: Recreated the container forcing the root user (-u root) to bypass any potential host/container permission conflicts on the mounted volume. The behavior persists.

Error Stack Trace:

{
  "errorMessage": "The file \"/data/poema.json\" is not writable.",
  "errorDetails": {
    "rawErrorMessage": [
      "The file \"/data/poema.json\" is not writable."
    ]
  },
  "n8nDetails": {
    "nodeName": "Read/Write Files from Disk",
    "nodeType": "n8n-nodes-base.readWriteFile",
    "nodeVersion": 1.1,
    "operation": "write",
    "itemIndex": 0,
    "n8nVersion": "2.26.4 (Self Hosted)",
    "stackTrace": [
      "NodeApiError: The file \"/data/poema.json\" is not writable.",
      "    at ExecuteContext.execute (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-nodes-base@file+packages+nodes-base_@aws-sdk+credential-providers@3.808.0_asn1.js@5_8da18263ca0574b0db58d4fefd8173ce/node_modules/n8n-nodes-base/nodes/Files/ReadWriteFile/actions/write.operation.ts:130:10)"
    ]
  }
}
Given that this happens even inside /tmp/ within a container running as root, it looks like a false negative in the node's internal validation logic (specifically around write.operation.ts:130).
Is this a known regression in v2.26.x or is there any specific environment variable I should tweak to fix this validation check?
Thanks in advance for your help!

## What is the error message (if any)?

{
"errorMessage": "The file "/data/poema.json" is not writable.",
"errorDetails": {
"rawErrorMessage": \[
"The file "/data/poema.json" is not writable."
\]
},
"n8nDetails": {
"nodeName": "Read/Write Files from Disk",
"nodeType": "n8n-nodes-base.readWriteFile",
"nodeVersion": 1.1,
"operation": "write",
"itemIndex": 0,
"n8nVersion": "2.26.4 (Self Hosted)",
"stackTrace": \[
"NodeApiError: The file "/data/poema.json" is not writable.",
"    at ExecuteContext.execute (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-nodes-base@file+packages+nodes-base\_@aws-sdk+credential-providers@3.808.0_asn1.js@5_8da18263ca0574b0db58d4fefd8173ce/node_modules/n8n-nodes-base/nodes/Files/ReadWriteFile/actions/write.operation.ts:130:10)"
\]
}
}

## Please share your workflow

The workflow is a simple 3-node structure:
HTTP Request ➡️ Convert to File ➡️ Read/Write Files from Disk (Write operation).

The Convert to File node outputs binary data successfully (approx. 27.5 kB), but the execution stops completely at the Read/Write Files from Disk node.

## Share the output returned by the last node

I'm facing a persistent issue with the Read/Write Files from Disk node (v1.1) when trying to execute a "Write File to Disk" operation. It consistently throws the "is not writable" error, regardless of the folder, user permissions, or execution mode.
What I've tried so far to isolate the issue:
1. Native Windows: Targeted local folders (C:\n8n\poema.json) and temporary paths. Got the error.
2. Docker (Standard User): Mounted volume -v c:/n8n:/data and targeted /data/poema.json. Fails.
3. Docker Isolated Path: Tried writing directly into Docker container native paths like /tmp/poema.json and /home/node/poema.json. Fails with the exact same error.
4. Pre-creating the file: I manually created an empty poema.json file (0 KB) inside the destination folder to check if it was a creation vs update issue. Still throws "not writable".
5. Docker Root User: Recreated the container forcing the root user (-u root) to bypass any potential host/container permission conflicts on the mounted volume. The behavior persists.
Given that this happens even inside /tmp/ within a container running as root, it looks like a false negative in the node's internal validation logic (specifically around write.operation.ts:130).

## Information on your n8n setup

* **n8n version:**
* **Database (default: SQLite):**
* **n8n EXECUTIONS_PROCESS setting (default: own, main):**
* **Running n8n via (Docker, npm, n8n cloud, desktop app):**
* **Operating system:**


* n8n Version: 2.26.4 (Self Hosted)
* Database: SQLite (default)
* Execution Mode: Regular (and tested via Docker / WSL2 backend)
* Binary Data Mode: database (also tested with filesystem)

@uidb4056 great isolation, it points right at the cause: this isn’t OS permissions, it’s n8n’s own file-access gate. v2.0 shipped a breaking change locking down filesystem access for the Read/Write Files node, so it blocks the write before the OS sees it. That’s why root, 777, /tmp, and a manual touch all change nothing, it’s an application-level allowlist, not a filesystem permission.

The env var you want is N8N_RESTRICT_FILE_ACCESS_TO, set it to your target dir (semicolon-separated for multiple), e.g. /data, then restart n8n. Also check the path isn’t blocked by N8N_BLOCK_FILE_ACCESS_TO_N8N_FILES (default on, blocks .n8n).

If it still fails, it’s the known 2.x regression (GitHub #23318 / #24829), and the workaround is the Execute Command node, which writes fine where this node refuses.

In addition to what achamm has mentioned, if it is mulitiple directories then the above env var will not work. You will then need to set it this way:

N8N_RESTRICT_FILE_ACCESS_TO: ""

Scenario A: If you are writing raw text or JSON data

Pass the data dynamically using expressions:

Bash

echo '{{ JSON.stringify($json) }}' > /data/poema.json

(Or target your specific property, e.g., {{ $json.myText }})

Scenario B: If you are handling Binary Data

If the file content is coming from a previous node as a binary object, you can write the binary stream directly to disk using standard shell commands:

Bash

cat {{ $binary.data }} > /data/poema.json

This acts as a solid, foolproof workaround while waiting for a patch on the core validation logic in the readWriteFile node.

Hi @achamm,

Thank you so much! You nailed it.

The issue was indeed the application-level restriction introduced in v2.x. Recreating the Docker container with the environment variables you provided solved the problem completely:

-e N8N_RESTRICT_FILE_ACCESS_TO=/data -e N8N_BLOCK_FILE_ACCESS_TO_N8N_FILES=false

Once those were set, the Read/Write node worked perfectly inside the mounted volume without any permission errors. Marked as solution!

Your welcome! Happy to help!