Sftp keeps crashing NR


node-red-contrib-better-sftp will crash NR 2.2.2.
In Better-Sftp LIST is working, but PUT, GET and DELETE will crash NR.
In the console is then the error;

8 Aug 11:06:44 - [red] Uncaught Exception:
18 Aug 11:06:44 - [error] Error: sftp.realPath: The "string" argument must be of type string or an instance of Buffer or ArrayBuffer. Received type number (1660813604353) 1660813604353

After some looking around in noticed that this error is not coming from the Better-Sftp node but from his dependencies ssh2-sftp-client
Unfortunately the Better-Sftp node isn't updated for more then 2 years, but the dependencies ssh2-sftp-client is updated 14 days ago.

Is it possible to update only the dependecies to see if this fixes the problem? Where are they installed? Is it possible that updating the dependecies will break other nodes? Is it possible to see if other nodes uses this dependecies?


Yes. Change the dependency version number in package.json of that node package then run npm install

e.g. (assuming linux, use notepad instead of nano for windows)

cd ~/.node-red/node_modules/
cd node-red-contrib-better-sftp
nano package.json

edit the dep, save, then...

npm install

in node_modules under your .node-red dir (see node-red startup log for exact location)

not if you simply update the ssh2-sftp-client dependancy in the Better-Sftp node

Yes, but not really necessary.

I've been using a locally installed version with updated dependencies for a bit now, so I went ahead and uploaded the fork to npm today (the original dev doesn't seem very active). Perhaps it will resolve your issue, it is now available here: node-red-contrib-betterplus-sftp (node) - Node-RED

Thanks both for the reply.

I tried the version from Harold, but unfortunately this version also keeps crashing with the same error.
Most likely there is something different with my sftp server. I have cloud storage from stackstorage.com that also have the option to use sftp for up and downloading files. With FileZilla it works flawless, but with the sftp nodes in NR not.
Not worth to put to much time in it, will switch to webdav and see if that's working for me.

Going back to the error in the first message. I looked through the repo for the dependency and above the _realpath function is:

   * @async
   * Returns the real absolute path on the remote server. Is able to handle
   * both '.' and '..' in path names, but not '~'. If the path is relative
   * then the current working directory is prepended to create an absolute path.
   * Returns undefined if the path does not exists.
   * @param {String} remotePath - remote path, may be relative
   * @returns {Promise<String>} - remote absolute path or ''

Are you perhaps sending a timestamp/number as a value where a file-path/string is expected?

@HaroldPetersInskipp, regardless of what a msg or its payload contains, it is essential a custom node handles errors gracefully to prevent node-red crashing.

Typically, you would

  • wrap async code / callbacks in try/catch and raise node.error(err.description, msg) or done(err)
  • ensure promises have .catch handlers

I realise there are some errors in some buried dependency libs that cannot be caught (and this may be one of those cases) so it would be a good idea to (at minimum) mitigate it by doing a sanity check on the users input.


Yes, without question. My intention in bringing it up was going to be that it would likely be simple changes required to handle errors like his situation if he were inclined to make the modification himself.

1 Like

Thanks for your reply again.
I tested the sftp node with a inject node that indeed sends (by default) a time stamp. The error lead me a couple days ago also to the remotePath function and after reading the purpose of this function I came to the conclusion that there was something wrong with the absolute path on the remote server not something I did wrong in NR.
For testing I also filled in the complete node properties, so that the payload doesn't matter just like other nr-nodes.

However I tried what you suggested and changed the inject node payload to a string with Serial.txt, NR crashed again, now with the error Serial.txt file not found.
After changing the payload to noderedbackup/Serial.txt succes, file was deleted :wink:

Crashing NR on a file not found, incorrect payload and maybe some more basic file handling makes this as Steve also mentioned unstable. No proper error handle is done and this makes this node useless for me.

Looks like the node has been abandoned