Permission denied

I have an existing Node-Red flow that will append a record to a file on my NAS.
This has been running just file for many months.

Today, I migrated from my old NAS to a brand new Synology DS720+. Everything works OK, I created a user "Pi" with the approprate authorizations. Everything that is logged from my Domoticz is working OK.
But the Node-Red flow does not: permission denied!
Where's the catch? Doesn't Node-Red show as user Pi when appending?

additional info: I've changed the authorization requirements for the shared folder in the Synology to "everybody", including guest. Did not help.
Since it is recommended often on this forum, I have also re-run the installation script for Node-Red. nothing.

Please stop node-red and start it again in a terminal (using node-red-stop;node-red-start) and post the full log here up to the error. Copy/paste it here please (not a screen shot). Use the </> button at the top of the forum entry window when pasting it in.

Are you using user Pi (as you said) or pi, the default? They are not the same. Though since you have now allowed guest permission it probably isn't that.


pi@Utrecht:~ $ node-red-start

Start Node-RED

Once Node-RED has started, point a browser at http://10.0.0.199:1880
On Pi Node-RED works better with the Firefox or Chrome browser

Use   node-red-stop                          to stop Node-RED
Use   node-red-start                         to start Node-RED again
Use   node-red-log                           to view the recent log output
Use   sudo systemctl enable nodered.service  to autostart Node-RED at every boot
Use   sudo systemctl disable nodered.service to disable autostart on boot

To find more nodes and example flows - go to http://flows.nodered.org

Starting as a systemd service.
3 Dec 17:17:57 - [info]
Welcome to Node-RED
===================
3 Dec 17:17:57 - [info] Node-RED version: v2.1.4
3 Dec 17:17:57 - [info] Node.js  version: v12.22.7
3 Dec 17:17:57 - [info] Linux 5.10.63-v7l+ arm LE
3 Dec 17:17:58 - [info] Loading palette nodes
BAIL ON node-red-contrib-file-function/file-function
3 Dec 17:18:01 - [info] Dashboard version 2.28.1 started at /ui
3 Dec 17:18:01 - [warn] ------------------------------------------------------
3 Dec 17:18:01 - [warn] [node-red-node-rbe/rbe] 'rbe' already registered by module node-red
3 Dec 17:18:01 - [warn] ------------------------------------------------------
3 Dec 17:18:01 - [info] Settings file  : /home/pi/.node-red/settings.js
3 Dec 17:18:01 - [info] Context store  : 'default' [module=memory]
3 Dec 17:18:01 - [info] User directory : /home/pi/.node-red
3 Dec 17:18:01 - [warn] Projects disabled : editorTheme.projects.enabled=false
3 Dec 17:18:01 - [warn] Flows file name not set. Generating name using hostname.
3 Dec 17:18:01 - [info] Flows file     : /home/pi/.node-red/flows_Utrecht.json
3 Dec 17:18:01 - [warn]
---------------------------------------------------------------------
Your flow credentials file is encrypted using a system-generated key.
If the system-generated key is lost for any reason, your credentials
file will not be recoverable, you will have to delete it and re-enter
your credentials.
You should set your own key using the 'credentialSecret' option in
your settings file. Node-RED will then re-encrypt your credentials
file using your chosen key the next time you deploy a change.
---------------------------------------------------------------------
3 Dec 17:18:01 - [info] Server now running at http://127.0.0.1:1880/
3 Dec 17:18:01 - [info] Starting flows
3 Dec 17:18:01 - [warn]
---------------------------------------------------------------------
Patched https.request function detected. This will break the
HTTP Request node. The original code has now been restored.
This is likely caused by a contrib node including an old version of
the 'agent-base@<5.0.0' module.
You can identify what node is at fault by running:
   npm list agent-base
in your Node-RED user directory (/home/pi/.node-red).
---------------------------------------------------------------------
3 Dec 17:18:01 - [info] Started flows
3 Dec 17:18:02 - [info] [mqtt-broker:698d3ae2.89ac94] Connected to broker: mqtt://localhost:1883
3 Dec 17:18:02 - [info] [mqtt-broker:c8b01a2a.39d8e8] Connected to broker: mqtt://localhost:1883
3 Dec 17:18:02 - [info] [mqtt-broker:b43c0abe.3a2a98] Connected to broker: mqtt://localhost:1883
3 Dec 17:18:02 - [info] [mqtt-broker:Winterswijk] Connected to broker: mqtt://www.winterswijk28.duckdns.org:1883
3 Dec 17:18:02 - [info] [buienradar:Groenlo] Error: TypeError: Cannot set property 'titel' of undefined
3 Dec 17:18:02 - [info] [buienradar:De Bilt] Error: TypeError: Cannot set property 'titel' of undefined
3 Dec 17:18:07 - [info] nora: connected, uid: zFYSOzW4NnM2L8qCM0dM25i14Vx2
3 Dec 17:18:08 - [info] nora: synced 7 device(s), group: <default>
3 Dec 17:18:26 - [error] [file:store in file] failed to append to file: Error: EACCES: permission denied, open '/home/pi/myNAS/myShare/logfiles/Watermeter Winterswijk.t        xt'

This is what came out of the file node:

failed to append to file: Error: EACCES: permission denied, open '/home/pi/myNAS/myShare/logfiles/Watermeter Winterswijk.txt'

I realize there is a blank in the filename, but this has always been the case.
I also made sure there is a user "pi" with generous authorization...

But even then, all file actions coming out of Domoticz (on the same Pi!) are running just fine.
Is node-red running as a different user somehow? How can I tell?

I suspect the problem is that the filenam appear to have a gap in the middle of .t xt
If you are passing the filename in to the node then add a debug node before it and check what the filename looks like.

Also you should sort out the other problems identified in the log.

Filename is hard-coded in the file node....

/home/pi/myNAS/myShare/logfiles/Watermeter Winterswijk.txt

The blank in the filetype is probably caused by cut/paste.

Other issuses are warnings, not errors...

I didn't say they are errors, I said they were problems. You should sort them out. When something you don't understand is happening always first fix any issues that are simpler to fix, even if you think they are unrelated. Often issues have side effects that are not obvious.

Also, in a terminal, what does this show
ls -l "/home/pi/myNAS/myShare/logfiles/Watermeter Winterswijk.txt"
Copy/paste that into the command please.

Show us how you have configured the file node.

-rwxr-xr-x 1 root root 7176 Dec  2 21:50 '/home/pi/myNAS/myShare/logfiles/Watermeter Winterswijk.txt'

[{"id":"a9c9c009.016f2","type":"file","z":"467d8533.2b9cbc","name":"store in file","filename":"/home/pi/myNAS/myShare/logfiles/Watermeter Winterswijk.txt","appendNewline":true,"createDir":false,"overwriteFile":"false","encoding":"none","x":410,"y":400,"wires":[["1e74c6ca.7fe799","eaefe251.e02ac"]]}]

I checked in another flow where I read from this file. Seems to work fine.
So it is specifically the write/append that falls over.

So user root has rw access, and others have read only access. Hence you cannot write to it as user pi.

Could that be it? How can I change that?
I did not expect any changes like this when doing a one-to-one change in NAS, but I guess security may be slightly different!

I would change the owner to pi

I've tried a few different things.
I removed the two faulty weather stations, so node-red now starts without errors.

Then, I updated the file using nano, saved to disk. This is done from the pi logon, and works just fine.
After this the node-red flow still cannot write.
Then I renamed the old file to a different name, so the node-red flow doesn't see any file and should create a new file: still no-go.
I also tried changing ownership of the file using chown, but when I look at ls -l, it stays connected to root!


pi@Utrecht:~/myNAS/myShare/logfiles $ ls -l 'Watermeter Winterswijk.txt'
-rwxr-xr-x 1 root root 7168 Dec  5 13:48 'Watermeter Winterswijk.txt'
pi@Utrecht:~/myNAS/myShare/logfiles $ sudo chown pi 'Watermeter Winterswijk.txt'
pi@Utrecht:~/myNAS/myShare/logfiles $ ls -l 'Watermeter Winterswijk.txt'
-rwxr-xr-x 1 root root 7168 Dec  5 13:48 'Watermeter Winterswijk.txt'
pi@Utrecht:~/myNAS/myShare/logfiles $

Exactly what command did you use to do that?

What command did you use for that? Run it again and then run the ls command. Make sure it is really gone.

Hmm... I tried again. When I use nano it warns me that the file is unwritable. When I use 'sudo nano' it is OK... so there must be something in the ownership!

Tried chown, but I don't understand:

 pi@Utrecht:~/myNAS/myShare/logfiles $ ls -l 'Watermeter Winterswijk.txt'
-rwxr-xr-x 1 root root 7168 Dec  5 13:48 'Watermeter Winterswijk.txt'
pi@Utrecht:~/myNAS/myShare/logfiles $ sudo chown pi 'Watermeter Winterswijk.txt'
pi@Utrecht:~/myNAS/myShare/logfiles $ ls -l 'Watermeter Winterswijk.txt'
-rwxr-xr-x 1 root root 7168 Dec  5 13:48 'Watermeter Winterswijk.txt'
pi@Utrecht:~/myNAS/myShare/logfiles $

I expected the ownership to change, but it doesn't!

OK, different approach. I copied the file back to local storage on the Pi.
Then changed ownership to pi, and granted masx authorization. Now see:

pi@Utrecht:~ $ ls water.txt -l
-rw-rw-rw- 1 pi root 7168 Dec  5 15:49 water.txt
pi@Utrecht:~ $

Looks, OK, right?
Then copied the file out to the NAS share, and this is what I see:

pi@Utrecht:~/myNAS/myShare/logfiles $ ls -l water.txt
-rwxr-xr-x 1 root root 7168 Dec  5 15:58 water.txt
pi@Utrecht:~/myNAS/myShare/logfiles $

So, as result of the copy, the authorization and ownership changed. Must have something to do with the NAS authorizations...
But the weird thing is the fact that all file logging that I do from Domoticz LUA scripts run just fine!

What does ls -l show for the log files?
Also what happens if you create a new file directly in the share, using nano?

output from ls:

-rwxr-xr-x 1 root root   7168 Dec  5 15:51 'Watermeter Winterswijk.txt'

Tried to create new file. When using sudo, it works. Without it, it shows message "directory is not writable".

So, basically, Domoticz works OK, Node-Red does not. Is there a way to make Node-Red run as root?