But seriously, should we consider whether installing in WSL should be our recommended route to node-red in Windows?
I don't believe it should be the first choice. It is an optional component after all and really designed to help people migrate to Windows
Node.js apps work fine on Windows natively and many people just want to run node-red as an app anyway and PM2 is great to facilitate that. The main issue is that the average Windows user never has to get to grips with running things as services so doesn't understand the details. Also, relatively few of us (myself included generally) don't run node-red as a service since a Linux server is generally a lot cheaper for that kind of thing.
Been using it a couple of weeks
I'm not on Insiders for my daily-driver pc so I can't use it yet. Looking forward to it though.
Hi Colin,
i couldn't agree more with you on this, having happily experienced NR on a raspbian since 2018.
I was somehow forced to go windows because I need to use ETS 6.x ( the official KNX project Management) that, unfortunately, runs on Windows only (not even virtualized according to the official doc).
I learnt from this thread about the promising WSL/systemd route. For the time being I will run NR from command node-red as a current user process and not as a system owned service that proved so problematic.
To be honest with you I have not understood whether NR as a system owned service can or can't have access to the local images referenced inside a template node. From the experience I had I understand it can't, but officially nobody told me.
I'm asking that for the benefit of future NR users on windows platform so they can be warned about this limiting issue should they read this post.
Thank you again for your patience and support.
There are two issues there. Firstly the user running node red (SYSTEM in this case) must be able to access the files. Secondly, httpStatic must be set correctly. It is likely that the settings.js file that was being used is not the one you edited. Had you edited the one actually in use it may well have worked.
[Edit] The best solution is to configure NSSM to run node red as the correct user, with the correct working directory, as I think was suggested earlier in the thread.
I've also done some reading up of Docker on Windows. Seems like ALL of the ways of running standard containers on Windows all require WSL as well.
Will do some more research on running node.js apps as Windows services to see if there are better options than nssm since last I looked. Native is pretty much always going to be better than virtualised on Windows desktops I think.
Yes, that is still the recommendation - at least for now.
To clarify, I think Julian means it is recommended that you run node-red/node js natively and is NOT recommending that you run it as your own user account.
The better solution is to use the system
account and only resort to using a separate (limited) account if the system account has insufficient permissions for what you are trying to achieve.
The bottom line is if you actually revert back to exactly what you had, but you use a separate folder and give it the correct permissions, all of this would just continue to work nice and easily.
My recommendation would be...
- move your node-red userDir to
c:\something
- make sure the service account AND your user account have read-write access
- set NSSM to run
node-red -p 1880 -u c:/something
- set the NSSM "log" tab up to output STDOUT and STDERR to write to log files in
c:/something
and enable log rotation- Enable NSSM
NOTE:
c:\something
should really be something likec:\node-red-1880
- the above was for illustration purposes
To clarify, I think Julian means it is recommended that you run node-red/node js natively and is NOT recommending that you run it as your own user account.
The better solution is to use the
system
account and only resort to using a separate (limited) account if the system account has insufficient permissions for what you are trying to achieve.
To clarify I recommend using a specific user id to run node-red if you wish to have it permanently running in the background. SYSTEM has a lot of access and might be abused. This is in line with my security recommendations for running node-red under Linux too.
If you simply want to run it periodically as a Windows app, I recommend using PM2 to run it under your current user id - you can use the package.json in your userDir folder to define some npm scripts to start/restart and show logs. You can also use a watch list for auto-restart after key file changes.
The other approach is to turn on IIS which is Windows' web server and it can be used as a reverse proxy. There is an extension for it that lets it manage node.js services directly. I need to dig out the name of that.
I feel an FAQ coming on!
Hi Steve,
I stubbornly tried to keep SYSTEM account before eventually giving up. I repeatedly checked, via Windows folder permissions dialogue, that SYSTEM user had all possible rights on C:\domotica folder. I then edited settings.js in "C:\Users\rober\AppData\Roaming\npm\node_modules\node-red\settings.jsā (the only other settings.js to be found in the machine) enabling httpStatic to "C:\domoticaā, closing and restarting the machine and therefore the process. Still the images were not accessible. BTW, following your suggestion, I changed that folder position as well and edited settings.js accordingly.
According to my findings it might be on or the other:
- node-red launched as a service by SYSTEM is not using settings.js at all
- node-red uses a settings.js located in an user not accessible position so it cannot be edited and enable HTTPStatic.
- node-red launched by SYSTEM is somehow sandboxed in his service and has not the rights to the folder we otherwise see from folder permissions.
In any case the issue turned out too complex for my forces and experience on windows platform and I eventually gave up.
Now Iām happily seeing my images with template node and the only way I found was launching node-red with its command ānode-redā ad a current user process.
One final favour, can you confirm that the user flows goes in "C:\Users\rober.node-red\flows.jsonā? Do you know where all added installed nodes go? I would backup what is necessary for a fast restore in case of a disaster.
Once again thank you for your patience.
node-red uses a settings.js located in an user not accessible position so it cannot be edited and enable HTTPStatic.
Unless you enable the logs and look to see where it is getting it from then you will never know.
One final favour, can you confirm that the user flows goes in "C:\Users\rober.node-red\flows.jsonā? Do you know where all added installed nodes go? I would backup what is necessary for a fast restore in case of a disaster.
If the user id used to run node-red is rober
, then the default userDir folder will be C:\Users\rober\.node-red\
(note the additional \
).
All of the instance definitions exist within that folder unless directed elsewhere. Flows, settings, etc.
One final favour, can you confirm that the user flows goes in "C:\Users\rober.node-red\flows.jsonā? Do you know where all added installed nodes go? I would backup what is necessary for a fast restore in case of a disaster.
Look in the startup log to confirm which flows file it is using.
By default the installed nodes go in the node_modules subfolder of the same folder the flows are in, so usually .node-red/node_modules. However generally you should not back that up as it can be very large and contains compiled code that may not work when you restore it (if nodejs has been updated to a new major version for example). The definitions of which nodes to installed is in .node-red/package.json and package-lock.json. Generally one should back up the whole of the .node-red folder except for node_modules. Then if one has to restore, go into the .node-red folder and run
npm install
which will look in the package files and install and recompile everything you need.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.