Ressources · Intégration n8n

Nœud Read/Write Files from Disk n8nConfigurer Read/Write Files from Disk dans n8n.

Le nœud Read/Write Files from Disk n8n travaille sur le disque de la machine qui fait tourner n8n. Deux opérations : une qui écrit un champ binaire dans un fichier, une qui relit un chemin ou tout un motif de chemins. Rien à authentifier, et les répertoires accessibles dépendent de l'endroit où tourne n8n.

Tester le nœud Read/Write Files from Disk sur n8nVoir les 2 opérations

Avis vérifiés sur Trustpilot · Agence IA, automatisation & growth

Pourquoi automatiser

À quoi sert le nœud Read/Write Files from Disk n8n ?

Il lit ou écrit des fichiers sur l'ordinateur qui exécute n8n. Côté écriture, il prend un champ binaire déjà porté par l'item et le pose sur le disque sous le nom que tu choisis. Côté lecture, il transforme un chemin, ou un motif qui en désigne plusieurs, en données binaires sur les items qui sortent. Il ne démarre jamais un workflow tout seul : un déclencheur passe avant, puis le nœud s'exécute une fois par item reçu.

Premier scénario, l'archivage d'un document. Une facture générée plus haut dans le workflow arrive sous forme de champ binaire, File Path and Name construit le chemin de destination avec l'extension, et le fichier atterrit dans un dossier monté sur la machine. Un message part ensuite dans Slack avec la référence, personne ne cherche le document trois jours après.

Deuxième scénario, la reprise d'un dossier entier. Le motif passé à File(s) Selector attrape tous les exports déposés par un prestataire, chaque fichier ressort comme un item distinct, et Edit Fields (Set) remet un peu d'ordre dans les métadonnées avant le traitement. Le nom du fichier vient souvent d'un champ de l'item, sous la forme {{ $json.reference }}.

Troisième scénario, le journal qui s'allonge. Avec Append activé, chaque exécution ajoute sa ligne au fichier existant au lieu de l'écraser. Sur du texte, ça marche très bien. Sur un format binaire structuré, ça n'a pas de sens, et la doc le dit sans détour.

Quand vaut-il mieux prendre autre chose ? Dès que le fichier doit survivre à l'exécution. n8n renvoie alors vers un nœud de stockage cloud, AWS S3, Google Drive ou FTP. Et si le fichier n'est pas sur un disque mais derrière une API, c'est HTTP Request qu'il faut : il appelle n'importe quel endpoint HTTP, mais rien qui parle un autre protocole.

Restent les limites, et elles comptent. Sur n8n Cloud, le nœud n'accède qu'aux chemins sous /home/node/ : tout ce qui est ailleurs, /tmp/ ou /data/ compris, échoue avec une erreur d'accès. Les valeurs affichées dans les champs ne sont que des exemples à remplacer, le répertoire /home/node/.n8n/ est réservé à n8n, et rien ne garantit qu'un fichier écrit là survive à une exécution, au redémarrage d'un worker ou à un redéploiement. En auto-hébergé, le nœud atteint par défaut tout ce que le processus n8n atteint, sauf si N8N_RESTRICT_FILE_ACCESS_TO le restreint à une liste de répertoires séparés par des points-virgules ; à partir de n8n 2.0, cette variable vaut ~/.n8n-files par défaut, donc travailler ailleurs se déclare explicitement. Sous Docker, les chemins sont ceux du conteneur, pas ceux de l'hôte : un dossier de l'hôte se monte en volume. Et n8n recommande les chemins absolus. L'Avis n8n détaille ce que ce choix d'hébergement change au quotidien.

Actions

Quels champs remplir pour chaque opération ?

Le nœud Read/Write Files from Disk expose 2 opérations. Pour chacune : le nœud tel que tu le configures dans n8n, les champs obligatoires, et nos notes de terrain.

01

Read File(s) From Disk

read

Ce que tu vois dans n8n

Notes & cas d'usage

Cette opération récupère un ou plusieurs fichiers depuis l'ordinateur qui exécute n8n et les renvoie en données binaires. Un chemin, un fichier ; un motif, tout un dossier en une passe.

Paramètres clés

  • File(s) Selector : requis, le chemin ou le motif de chemin, avec des barres obliques même sous Windows (/home/user/Pictures/**/*.png). * s'arrête au séparateur de chemin, ** le traverse.
  • Put Output File in Field : le champ binaire de sortie qui porte le fichier, data par défaut.
  • File Name et File Extension : le nom et l'extension attachés au binaire de sortie.
  • Mime Type : le type MIME du binaire de sortie, application/zip pour une archive.
Cas d'usage
relire les exports déposés dans un dossier de la nuit, chacun ressortant comme un item à traiter.
02

Write File to Disk

write

Ce que tu vois dans n8n

Notes & cas d'usage

Le sens de circulation s'inverse : le nœud prend un champ binaire déjà présent sur l'item et crée un fichier avec, sur l'ordinateur qui exécute n8n, extension comprise.

Paramètres clés

  • File Path and Name : requis, le chemin de destination, le nom du fichier et son extension (/data/example.jpg), en absolu comme le recommande n8n.
  • Input Binary Field : requis, le nom du champ binaire d'entrée qui contient le fichier, data dans la plupart des workflows.
  • Append : activé, le contenu s'ajoute à un fichier existant au lieu d'en créer un nouveau. Courant sur du texte, inadapté aux formats binaires à structure fixe.
Cas d'usage
poser le PDF signé d'un contrat dans le dossier qu'un outil local surveille déjà.
Besoin d'aide

Besoin d'aide pour automatiser Read/Write Files from Disk avec n8n ?

L'équipe te répond directement.

Chaque message est lu par une personne.

FAQ

Les questions qu'on se pose ensuite

01Le nœud Read/Write Files from Disk n8n est-il inclus sur Cloud comme en auto-hébergé ?
Oui. C'est un nœud core livré avec n8n : aucune installation à prévoir, aucun coût supplémentaire côté n8n, aussi bien sur n8n Cloud que sur une instance auto-hébergée en Community Edition sous licence Sustainable Use. Le workflow se construit exactement de la même façon dans les deux cas. Ce qui change, ce n'est pas le nœud mais le disque qu'il peut atteindre : sur Cloud, uniquement les chemins sous /home/node/ ; en auto-hébergé, tout ce que le processus n8n atteint, dans les limites posées par la variable N8N_RESTRICT_FILE_ACCESS_TO.
02Que faut-il configurer avant de l'utiliser ?
Rien côté compte. Ce nœud n'a ni credential, c'est-à-dire un identifiant enregistré dans n8n, ni sélecteur Authentication : pas de clé à coller, pas d'écran OAuth, pas de droit à accorder. Deux conditions restent nécessaires. Un déclencheur doit s'exécuter avant lui, un Schedule Trigger ou un Webhook par exemple, puisque ce nœud réagit aux items entrants et n'ouvre pas un workflow. Et le chemin visé doit être accessible au processus n8n : sous /home/node/ sur Cloud, dans les répertoires autorisés par N8N_RESTRICT_FILE_ACCESS_TO en auto-hébergé.
03Quelles sont les limites du nœud ?
Il expose 2 opérations, lire et écrire, et rien d'autre. Le vrai point dur, ce sont les chemins. Sur Cloud, tout ce qui sort de /home/node/ échoue avec une erreur d'accès, le répertoire /home/node/.n8n/ est réservé à l'état interne de n8n, et un fichier écrit sur ce disque n'est pas garanti de survivre à une exécution, au redémarrage d'un worker ou à un redéploiement : rien d'important ne doit y rester. En auto-hébergé depuis n8n 2.0, N8N_RESTRICT_FILE_ACCESS_TO vaut ~/.n8n-files par défaut. Sous Docker, les chemins sont ceux du conteneur, donc un dossier de l'hôte se monte en volume.
04Quand choisir un autre nœud à la place ?
Dès que le fichier doit durer au-delà de l'exécution. Pour un stockage persistant, n8n oriente vers un nœud de stockage cloud, AWS S3, Google Drive ou FTP, et le conseil vaut surtout sur Cloud, où le système de fichiers est éphémère. Ce nœud garde tout son sens quand le fichier appartient vraiment à la machine qui exécute n8n : un volume monté, un dossier surveillé par un outil local, un fichier de travail le temps d'une exécution. Et si la ressource se trouve derrière une API plutôt que sur un disque, c'est HTTP Request qui s'en charge, puisqu'il appelle n'importe quel endpoint HTTP et rien au-delà.
05n8n ou Make pour manipuler des fichiers ?
Tout dépend de l'endroit où les fichiers ont le droit de vivre. Make est une plateforme d'automatisation hébergée, sans option d'auto-hébergement, facturée à l'opération, avec une logique visuelle qui convient aux équipes qui ne veulent rien faire tourner chez elles. n8n s'auto-héberge avec Docker ou npm, ce qui correspond exactement à ce que suppose ce nœud : le disque lu et écrit est un disque que tu contrôles, monté dans le conteneur de ton choix. Fichiers confidentiels ou volume important qui rendrait la facturation à l'opération douloureuse, l'auto-hébergement garde la donnée et le coût de ton côté.
Hack'celeration Lab

Reçois nos tips intégration chaque semaine.

Pas de spam. Désinscription à tout moment.

Même plateforme

Autres docs utiles sur ce stack.

Voir toutes les intégrations