Le nœud Read/Write Files from Disk génère l'erreur "is not writable" sur plusieurs environnements (Windows & Docker) - v2.26.4

Décrivez le problème/l’erreur/la question

Bonjour à tous,
Je rencontre un problème persistant avec le nœud Read/Write Files from Disk (v1.1) lors de la tentative d’exécution d’une opération « Write File to Disk ». Il lance systématiquement une erreur indiquant que le fichier n’est pas accessible en écriture, indépendamment du dossier, des permissions utilisateur ou du mode d’exécution.

Mon environnement :

  • Version n8n : 2.26.4 (Auto-hébergé)
  • Mode d’exécution : Testé à la fois sur Windows natif (configuration Node.js) et via Docker Desktop (backend WSL2).
  • Mode base de données : Testé avec binaryDataMode: filesystem et binaryDataMode: database.

Ce que j’ai déjà essayé :

  1. Windows natif : Ciblage de dossiers locaux (C:\n8n\poema.json) et chemins temporaires. Erreur « non accessible en écriture ».
  2. Docker (utilisateur standard) : Volume monté -v c:/n8n:/data et cible /data/poema.json. Échoue.
  3. Chemin isolé Docker : Tentative d’écriture directement dans les chemins natifs du conteneur Docker comme /tmp/poema.json et /home/node/poema.json. Échoue avec exactement la même erreur.
  4. Pré-création du fichier : J’ai créé manuellement un fichier poema.json vide (0 KB) dans le dossier de destination pour vérifier s’il s’agissait d’un problème de création ou de mise à jour. Lance toujours « non accessible en écriture ».
  5. Utilisateur root Docker : Récréation du conteneur en forçant l’utilisateur root (-u root) pour contourner les conflits de permissions potentiels entre l’hôte et le conteneur sur le volume monté. Le comportement persiste.

Trace de pile d’erreur :

{
  "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)"
    ]
  }
}
Étant donné que cela se produit même dans /tmp/ au sein d'un conteneur exécuté en tant que root, il semble s'agir d'un faux négatif dans la logique de validation interne du nœud (spécifiquement autour de write.operation.ts:130).
S'agit-il d'une régression connue dans v2.26.x ou existe-t-il une variable d'environnement spécifique que je devrais modifier pour corriger cette vérification de validation ?
Merci d'avance pour votre aide !

## Quel est le message d'erreur (le cas échéant) ?

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

## Veuillez partager votre workflow

Le workflow est une simple structure à 3 nœuds :
HTTP Request ➡️ Convert to File ➡️ Read/Write Files from Disk (opération Write).

Le nœud Convert to File génère des données binaires avec succès (env. 27,5 kB), mais l'exécution s'arrête complètement au nœud Read/Write Files from Disk.

## Partagez la sortie renvoyée par le dernier nœud

Je rencontre un problème persistant avec le nœud Read/Write Files from Disk (v1.1) lors de la tentative d'exécution d'une opération « Write File to Disk ». Il lance systématiquement l'erreur « non accessible en écriture », indépendamment du dossier, des permissions utilisateur ou du mode d'exécution.
Ce que j'ai essayé jusqu'à présent pour isoler le problème :
1. Windows natif : Ciblage de dossiers locaux (C:\n8n\poema.json) et chemins temporaires. Erreur reçue.
2. Docker (utilisateur standard) : Volume monté -v c:/n8n:/data et cible /data/poema.json. Échoue.
3. Chemin isolé Docker : Tentative d'écriture directement dans les chemins natifs du conteneur Docker comme /tmp/poema.json et /home/node/poema.json. Échoue avec exactement la même erreur.
4. Pré-création du fichier : J'ai créé manuellement un fichier poema.json vide (0 KB) dans le dossier de destination pour vérifier s'il s'agissait d'un problème de création ou de mise à jour. Lance toujours « non accessible en écriture ».
5. Utilisateur root Docker : Récréation du conteneur en forçant l'utilisateur root (-u root) pour contourner les conflits de permissions potentiels entre l'hôte et le conteneur sur le volume monté. Le comportement persiste.
Étant donné que cela se produit même dans /tmp/ au sein d'un conteneur exécuté en tant que root, il semble s'agir d'un faux négatif dans la logique de validation interne du nœud (spécifiquement autour de write.operation.ts:130).

## Informations sur votre configuration n8n

* **Version n8n :**
* **Base de données (par défaut : SQLite) :**
* **Paramètre EXECUTIONS_PROCESS de n8n (par défaut : own, main) :**
* **Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) :**
* **Système d'exploitation :**


* Version n8n : 2.26.4 (Auto-hébergé)
* Base de données : SQLite (par défaut)
* Mode d'exécution : Régulier (et testé via Docker / backend WSL2)
* Mode Binary Data : database (également testé avec filesystem)

@uidb4056 excellente isolation, ça pointe directement la cause : ce ne sont pas les permissions du système d’exploitation, c’est la barrière d’accès aux fichiers propre à n8n. La v2.0 a livré un changement qui casse la compatibilité en verrouillant l’accès au système de fichiers pour le nœud Read/Write Files, donc il bloque l’écriture avant que le système d’exploitation ne la voie. C’est pourquoi root, 777, /tmp, et un touch manuel ne changent rien, c’est une liste blanche au niveau application, pas une permission du système de fichiers.

La variable d’environnement que tu veux est N8N_RESTRICT_FILE_ACCESS_TO, définis-la sur ton répertoire cible (séparé par des points-virgules pour plusieurs), par exemple /data, puis redémarre n8n. Vérifie aussi que le chemin n’est pas bloqué par N8N_BLOCK_FILE_ACCESS_TO_N8N_FILES (activé par défaut, bloque .n8n).

Si ça échoue quand même, c’est la régression connue en 2.x (GitHub #23318 / #24829), et la solution de contournement est le nœud Execute Command, qui écrit sans problème là où ce nœud refuse.

En plus de ce qu’achamm a mentionné, s’il s’agit de plusieurs répertoires, la variable d’environnement ci-dessus ne fonctionnera pas. Vous devrez alors la configurer de cette façon :

N8N_RESTRICT_FILE_ACCESS_TO: ""

Scénario A : Si vous écrivez du texte brut ou des données JSON

Transmettez les données dynamiquement en utilisant des expressions :

Bash

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

(Ou ciblez votre propriété spécifique, par exemple, {{ $json.myText }})

Scénario B : Si vous gérez des données binaires

Si le contenu du fichier provient d’un nœud précédent en tant qu’objet binaire, vous pouvez écrire le flux binaire directement sur le disque en utilisant des commandes shell standard :

Bash

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

Ceci agit comme une solution solide et fiable en attendant un correctif sur la logique de validation de base dans le nœud readWriteFile.

Salut @achamm,

Merci beaucoup ! Tu as trouvé !

Le problème venait effectivement de la restriction au niveau de l’application introduite en v2.x. Recréer le conteneur Docker avec les variables d’environnement que tu as fournies a complètement résolu le problème :

-e N8N_RESTRICT_FILE_ACCESS_TO=/data -e N8N_BLOCK_FILE_ACCESS_TO_N8N_FILES=false

Une fois définies, le nœud Read/Write a fonctionné parfaitement dans le volume monté sans aucune erreur de permission. Marqué comme solution !

De rien ! Ravi de t’aider !