Problem/Fehler/Frage beschreiben
Hallo zusammen,
Ich habe ein hartnäckiges Problem mit dem Knoten „Read/Write Files from Disk
@uidb4056 großartig eingegrenzt, das zeigt direkt auf die Ursache: das sind keine OS-Berechtigungen, sondern n8n’s eigenes Datei-Zugriffs-Gate. v2.0 brachte einen Breaking Change mit eingeschränktem Dateisystem-Zugriff für den Read/Write Files-Node, daher blockiert es den Schreibzugriff, bevor das OS ihn sieht. Das ist der Grund, warum root, 777, /tmp und ein manuelles touch nichts ändern – es ist eine Allowlist auf Anwendungsebene, keine Dateisystem-Berechtigung.
Die Umgebungsvariable, die du brauchst, ist N8N_RESTRICT_FILE_ACCESS_TO, setz sie auf dein Zielverzeichnis (Semikolon-getrennt für mehrere), z. B. /data, und starten dann n8n neu. Überprüfe auch, ob der Pfad nicht durch N8N_BLOCK_FILE_ACCESS_TO_N8N_FILES blockiert wird (standardmäßig aktiviert, blockiert .n8n).
Falls es immer noch fehlschlägt, ist es die bekannte 2.x-Regression (GitHub #23318 / #24829), und der Workaround ist der Execute Command-Node, der dort ohne Probleme schreibt, wo dieser Node sich weigert.
Zusätzlich zu dem, was achamm erwähnt hat: Falls es mehrere Verzeichnisse sind, funktioniert die obige Umgebungsvariable nicht. Du musst sie dann so setzen:
N8N_RESTRICT_FILE_ACCESS_TO: ""
Szenario A: Wenn du rohen Text oder JSON-Daten schreibst
Übergib die Daten dynamisch mit Ausdrücken:
Bash
echo '{{ JSON.stringify($json) }}' > /data/poema.json
(Oder wende dich auf deine spezifische Eigenschaft, z. B. {{ $json.myText }})
Szenario B: Wenn du mit Binärdaten arbeitest
Wenn der Dateiinhalt von einem vorherigen Knoten als Binärobjekt kommt, kannst du den Binärstream direkt auf die Festplatte schreiben, indem du Standard-Shell-Befehle verwendest:
Bash
cat {{ $binary.data }} > /data/poema.json
Dies ist ein zuverlässiger, narrensicherer Workaround, während du auf einen Patch der Kernvalidierungslogik im readWriteFile-Knoten wartest.
Hallo @achamm,
Vielen Dank! Du hast es perfekt gelöst.
Das Problem war tatsächlich die Beschränkung auf Anwendungsebene, die in v2.x eingeführt wurde. Das Neuerstellen des Docker-Containers mit den Umgebungsvariablen, die du bereitgestellt hast, hat das Problem vollständig gelöst:
-e N8N_RESTRICT_FILE_ACCESS_TO=/data -e N8N_BLOCK_FILE_ACCESS_TO_N8N_FILES=false
Sobald diese gesetzt waren, funktionierte der Read/Write-Node perfekt im bereitgestellten Volume ohne Berechtigungsfehler. Als Lösung markiert!
Gerne geschehen! Ich helfe gerne!