Nó Read/Write Files from Disk lançando "is not writable" em múltiplos ambientes (Windows & Docker) - v2.26.4

Descreva o problema/erro/pergunta

Olá a todos,
estou enfrentando um problema persistente com o nó Read/Write Files from Disk (v1.1) ao tentar executar uma operação “Write File to Disk”. Ele lança consistentemente um erro informando que o arquivo não é gravável, independentemente da pasta, permissões de usuário ou modo de execução.

Meu Ambiente:

  • Versão n8n: 2.26.4 (Self Hosted)
  • Modo de Execução: Testado tanto no Windows nativo (setup Node.js) quanto via Docker Desktop (backend WSL2).
  • Modo de Banco de Dados: Testado com binaryDataMode: filesystem e binaryDataMode: database.

O que já tentei:

  1. Windows Nativo: Direcionei pastas locais (C:\n8n\poema.json) e caminhos temporários. Recebi o erro “not writable”.
  2. Docker (Usuário Padrão): Montei volume -v c:/n8n:/data e direcionei /data/poema.json. Falha.
  3. Caminho Isolado do Docker: Tentei gravar diretamente em caminhos nativos do container Docker como /tmp/poema.json e /home/node/poema.json. Falha com o mesmo erro.
  4. Pré-criando o arquivo: Criei manualmente um arquivo vazio poema.json (0 KB) dentro da pasta de destino para verificar se era um problema de criação versus atualização. Ainda lança “not writable”.
  5. Usuário Root do Docker: Recriei o container forçando o usuário root (-u root) para contornar possíveis conflitos de permissões entre o host e o container no volume montado. O comportamento persiste.

Stack Trace do Erro:

{
  "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)"
    ]
  }
}
Dado que isso acontece até dentro de /tmp/ dentro de um container rodando como root, parece ser um falso negativo na lógica de validação interna do nó (especificamente ao redor de write.operation.ts:130).
Isto é uma regressão conhecida na v2.26.x ou há alguma variável de ambiente específica que eu deveria ajustar para corrigir essa verificação de validação?
Obrigado antecipadamente pela ajuda!

## Qual é a mensagem de erro (se houver)?

{
"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)"
]
}
}

## Por favor, compartilhe seu workflow

O workflow é uma estrutura simples de 3 nós:
HTTP Request ➡️ Convert to File ➡️ Read/Write Files from Disk (operação Write).

O nó Convert to File retorna dados binários com sucesso (aproximadamente 27,5 kB), mas a execução para completamente no nó Read/Write Files from Disk.

## Compartilhe a saída retornada pelo último nó

estou enfrentando um problema persistente com o nó Read/Write Files from Disk (v1.1) ao tentar executar uma operação "Write File to Disk". Ele lança consistentemente o erro "is not writable", independentemente da pasta, permissões de usuário ou modo de execução.
O que já tentei para isolar o problema:
1. Windows Nativo: Direcionei pastas locais (C:\n8n\poema.json) e caminhos temporários. Recebi o erro.
2. Docker (Usuário Padrão): Montei volume -v c:/n8n:/data e direcionei /data/poema.json. Falha.
3. Caminho Isolado do Docker: Tentei gravar diretamente em caminhos nativos do container Docker como /tmp/poema.json e /home/node/poema.json. Falha com o mesmo erro.
4. Pré-criando o arquivo: Criei manualmente um arquivo vazio poema.json (0 KB) dentro da pasta de destino para verificar se era um problema de criação versus atualização. Ainda lança "not writable".
5. Usuário Root do Docker: Recriei o container forçando o usuário root (-u root) para contornar possíveis conflitos de permissões entre o host e o container no volume montado. O comportamento persiste.
Dado que isso acontece até dentro de /tmp/ dentro de um container rodando como root, parece ser um falso negativo na lógica de validação interna do nó (especificamente ao redor de write.operation.ts:130).

## Informações sobre sua configuração n8n

* **Versão n8n:**
* **Banco de Dados (padrão: SQLite):**
* **Configuração n8n EXECUTIONS_PROCESS (padrão: own, main):**
* **Executando n8n via (Docker, npm, n8n cloud, desktop app):**
* **Sistema Operacional:**


* Versão n8n: 2.26.4 (Self Hosted)
* Banco de Dados: SQLite (padrão)
* Modo de Execução: Regular (e testado via Docker / backend WSL2)
* Modo de Dados Binários: database (também testado com filesystem)

@uidb4056 ótimo isolamento, aponta direto para a causa: isso não é permissões do SO, é o próprio portão de acesso a arquivos do n8n. A v2.0 lançou uma mudança que quebra compatibilidade bloqueando o acesso ao filesystem para o nó Read/Write Files, então bloqueia a escrita antes do SO vê-la. É por isso que root, 777, /tmp e um touch manual não mudam nada, é uma allowlist no nível da aplicação, não uma permissão de filesystem.

A variável de ambiente que você quer é N8N_RESTRICT_FILE_ACCESS_TO, defina-a para seu diretório de destino (separado por ponto-e-vírgula para múltiplos), p.ex. /data, depois reinicie o n8n. Também verifique se o caminho não está bloqueado por N8N_BLOCK_FILE_ACCESS_TO_N8N_FILES (ativado por padrão, bloqueia .n8n).

Se ainda assim falhar, é a regressão conhecida da 2.x (GitHub #23318 / #24829), e a solução alternativa é usar o nó Execute Command, que escreve sem problemas onde este nó se recusa.

Além do que achamm mencionou, se houver múltiplos diretórios, a variável de ambiente acima não funcionará. Você precisará defini-la desta forma:

N8N_RESTRICT_FILE_ACCESS_TO: ""

Cenário A: Se você estiver escrevendo texto bruto ou dados JSON

Passe os dados dinamicamente usando expressões:

Bash

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

(Ou direcione sua propriedade específica, por exemplo, {{ $json.myText }})

Cenário B: Se você estiver lidando com Dados Binários

Se o conteúdo do arquivo vier de um nó anterior como um objeto binário, você pode escrever o fluxo binário diretamente no disco usando comandos de shell padrão:

Bash

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

Isso funciona como uma solução sólida e infalível enquanto aguarda um patch na lógica de validação principal do nó readWriteFile.

Oi @achamm,

Muito obrigado! Você acertou em cheio.

O problema era de fato a restrição no nível da aplicação introduzida na v2.x. Recriar o container Docker com as variáveis de ambiente que você forneceu resolveu o problema completamente:

-e N8N_RESTRICT_FILE_ACCESS_TO=/data -e N8N_BLOCK_FILE_ACCESS_TO_N8N_FILES=false

Uma vez que essas foram definidas, o nó Read/Write funcionou perfeitamente dentro do volume montado sem nenhum erro de permissão. Marcado como solução!

De nada! Fico feliz em ajudar!