Yes. I didn't want to write out the user, but whatever. There is one user, I use it, everything was installed with it. (not as root as I recall) But you're right, you have to reinstall everything from scratch, I just didn't know that you have to install things as user or root. (node red, recognizer, portaudio, audio device, etc.) so i try
thanks
(sorry for my poor english) 
If you aren't sure, install as a user unless that doesn't work.
Instructions will usually say if you need to use sudo. But be slightly wary if instructions tell you to use sudo to get access to server hardware - that is nearly always wrong - you should add your user to the appropriate security group rather than compromise security by making everything root.
I was able to do quite good things in node red, but I was always in trouble with these permissions, because, as you wrote, there are things that "require" the use of sudo, but then you can't access them properly from another application. I know how to add a user to a security group, but I don't always know where to add it. Thank you very much for the clarification, I understand much better now! (Uninstall sounddevice, reinstall sounddevice in global, but it didn't help)
Yes, permissions, especially hardware permissions in Linux can get complex. And you can see from the very many rubbish tutorials on the interweb that many people don't bother to even attempt to get this right.
But Linux permissions are fine-grained and not so hard to understand with a little effort.
Yes, but really not that many.
Here is an example from my home server's /dev folder:
You can see that some devices have a group setting of tty or dialout. So easy enough to connect a user to those. But some, like v4l for example are root/root - so should you give users root access to use that device? Well, no, that would be bad. Instead, that device needs changing to maybe give it group permissions of video. Because if you give your user root access, they can write to everything (change anything) and so if someone broke into your server (see another recent thread), they could do all sorts of damage or at least maybe access video streams they shouldn't be able to.
So often, a simple ls -l in a folder is enough to help you understand what needs doing.
Yes, that is a bad choice anyway since you would have to give Python apps root access.
Well, it's like:
if sudo systemctl enable nodered.service, then node red starts automatically with the raspberry, but the script does not run.
if systemctl enable nodered.service, then node red must be started from putty (node-red), the script runs, but if I exit putty, node red also stops
If there is a difference when you run with systemd rather than running node-red then it is a difference in the environment between those two.
Show us the systemd service script and tell us which user you are logged in as when you run node-red.
I wrote the system service script above.
(but by default : sudo systemctl enable nodered.service ) There is one user. Node red needs to start automatically with raspberry. Now I'm looking for (perhaps a solution) to start node red automatically, but as a user.
I believe that you need to use sudo to run systemd commands, except for systemctl status nodered.
If you run sudo systemctl enable nodered (the .service suffix is not necessary), then Node-red should start up automatically the next time you reboot.
The command to start or stop is sudo systemctl restart nodered or sudo systemctl stop nodered
How are you trying to start the script now?
Please show us the output of ls -l /full/pathname/file.py and head -1 /full/pathname/file.py for the script file
By all means falsify the actual username and script name in the output.
I can't see it. Please post it again.
You do that in the systemd service script.
I'm not running my script back and forth, I just described how I've tried it so far. My own script starts from putty with the same user that I specified in the raspberry imager during the raspberry installation. I tried in putty as a user and with sudo, but it doesn't run with sudo. I tried bigexec, exec, pythonsell nodes in node red, but the script did not run. But the last time I managed to run my script from node red was that in putty as a
user: sudo systemctl disable nodered.service,
then systemctl enable nodered.service,
then I started it with user: node-red,
and then in node red from bigexec I run my own script. If I speak into the microphone, my speech is displayed as text in the payload. This method is not good only because node red does not start automatically with raspberry because it is not sudo systemctl. I'm sorry for my poor English. I think we just misunderstand each other.
I am very grateful that you are trying to understand and help me 
That is correct. However, note that the sudo refers to systemctl and not to Node-RED. The script that systemd runs can contain a user and group definition that would be used for actually running Node-RED. See this for reference.
Also, enable only enables node-red to systemd, you also need to start it with:
sudo systemctl start nodered.service
Unless you want to reboot the device.
My understanding is that systemctl enable nodered will do nothing.
It certainly will not start node-red.
As @Colin says, the user which node-red runs as is specified in the systemd script.
You need to get control of
- The username that runs node-red at startup.
- The method of starting the python script from node-red
- How the operating system know which language the script should be interpreted as.
You seem strangely reluctant to share any of these details.
Then this would be the correct start? :
sudo systemctl enable nodered
sudo systemctl start nodered GalZoli:GalZoli
to automatically start as user when booting?
But that's the way it is:
/lib/systemd/system/nodered.service :
[Service]
Type=simple
# Run as normal pi user - change to the user name you wish to run Node-RED as
User=GalZoli
Group=GalZoli
WorkingDirectory=/home/GalZoli
You really want to put the user/group into the startup script - the example I gave shows how.
I think you can use sudo systemctrl edit --full nodered to use your command line editor to change the script.
Questions about installs and running seem to be cropping up again repeatedly with seemingly a new generation of Node-RED users. So I've created an FAQ:
Once you have enabled nodered it will start up automatically when you reboot.
There is normally no need to use sudo system start nodered.
The systemctl enable command tells it to start node red on boot.
The systemctl start command tells it to start node red now.
That tells it the user and group so you don't need to specify that in the systemctl start command. Just use
sudo systemctl start nodered
The systemctl enable command tells it to start node red on boot.
Yeah I know
The systemctl start command tells it to start node red now.
Yeah I know
sudo systemctl start nodered
Yeah I know
But this way my script doesn't run in node red.
Just like this:
GalZoli@raspberrypi:~ $ sudo systemctl disable nodered.service
[spoiler]GalZoli@raspberrypi:~ $ systemctl enable nodered.service[/spoiler]
GalZoli@raspberrypi:~ $ node-red
But this way node red does not start automatically
I will say it one more time and then I'm out.
The command systemctl enable nodered.service neither enables nor starts node-red
Since you are running it as the same user then it is something else in the environment that makes the difference. When you run it using just node-red then it uses the environment of the command window you are running in (PATH etc). When running via systemd script the environment is determined by what is in the systemd script.
If you add an exec node running the command
printenv
triggered by an inject node, then start node red with systemd and with node-red command you will see what the differences are. Something there is probably what is causing the problem.
If you try to run systemctl without sudo I would expect something like
$ systemctl enable nodered
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-unit-files ===
Authentication is required to manage system service or unit files.
Authenticating as: root
Password:
Though if you have the pi configured to not need passwords when you use sudo I am not sure what would happen. Configuring the pi like that is not a good idea.
