I use this command before a backup of my setup, to make sure that they go to the backup location on my server, which is mounted as a directory under /home/pi, but not always does that on startup. But on one Pi that I have now installed Bookworm on, I get "Command failed: sudo mount -a
/bin/bash: line 1: sudo: command not found". I'm guessing that's a breaking change in Bookworm, but is there a way around this without creating a shell script on the Pi and run that?
maybe install sudo and make it available to the user you are running as so you can call it ?
Thanks for answering! I have Node-RED running in a Docker container, so I'm not sure that's possible.
What do you expect mount to do when you are running in a container? The container does not have access to the host file system, except for explicitly shared folders.
Edit, but what has this got to do with whether node-red is running in a container? Are you trying to run the command from an exec node?
@Colin Yes I am trying that. I thought the subject of this thread said that clearly. And I had no idea that a container can't use sudo or access folders outside of themselves. But I will try to make a shell script in the Docker Compose directory for Node-RED that I can put into the container with a volume line in docker-compose.yml
Edit:No that didn't work either. A variation of the same message:
Command failed: sh /home/mount.sh
/home/mount.sh: line 2: sudo: not found
I assume that means that it can't run a sudo command that way either. So now my limited understanding of sudo and users is exhausted. Is there some way I can give Node-RED access to sudo commands from a container? I see that it makes it impossible for me to do backups of anything because I can't use the fs-ops-mkdir node either.
Yes it does, but I rarely read the subject. It is always best to give a full description of the problem in the text.
I don't think that it is sudo that is the problem, it is the fact that the container does not have access to kernel functions such as mount. A major reason for using Docker is so that it cannot mess with the system.
The solution is to fix whatever is causing it to not mount on startup. Alternatively don't run node-red in Docker unless you have a good reason to do so. Docker can cause more problems than it solves, as you are finding out.
The first solution is kind of impossible. There is nothing to fix because the reason for this is that the Pi isn't always physically in the same place as the network with the share is (it's in a boat, and the server with the share is in the cabin where the boat is docked). But I may have to reconsider Docker. Or maybe I can create a crontab script that runs every x minutes, checks if the Pi is connected to the network with the share and then connect.
At least I managed to give the container access the share directory through volumes in Docker Compose, so I could do the backup copy from within Node-RED.
That is probably the easiest solution.
@Colin Yeah, I think so too. The thing with Docker is that if necessary I can set up a new Pi (I have quite a lot of them in the boat, the car, the house, the cabin and so on) in a very short time by copying the /home/pi/docker directory, which contains the Docker Compose files with all special adjustments, and the /home/pi/Node-RED directory with the NR data, and the directories for Home Assistant data and a few other things I use a lot. Node-RED is quite the opposite of Hass, because installing without Docker there, called Core installation, has gotten close to impossible because of the weird dependencies and Python demands.
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
