I tried the named pipe solution and got some permission issues like others.
Solved this by changing user nobody by root and the same for nogroup.
It’s working great now and this allow me to switch on my NAS from anywhere through remote and secured access to Home Assistant.
This might give my family access to pictures archives at any time, without the need to keep the NAS constantly ON.
Thanks a lot Peter.
Great thought! The service definition was throwing errors in my setup for some reason, but creating a script such as the below and calling that one as ExecStart did the trick for me:
#!/bin/bash
pipe=/virtual/other/homeassistant/config/wolpipe
remac=“^([a-fA-F0-9]{2}:){5}[a-fA-F0-9]{2}$” # regex for mac address
while true
do
if read line <$pipe; then
if [[ “$line” =~ $re ]]; then
wakeonlan -i 192.168.2.99 $line # where 192.168.2.99 is the dummy target IP of my wol forwarder between subnets
fi
fi
done
Hi Gary.
I too got the permission error, when trying to test it (the echo command):
I had to changed the chmod value to 666 - e.i.:
sudo chmod 666 /path/to/homeassistant/config/wolpipe
This is a great solution, thanks a lot for sharing! I will only add that for me it was failing at first with
Permission denied at /usr/bin/wakeonlan
error, which I guess was because I created the pipe inside a root-owned directory. So I just re-created it at /opt/wolpipe (and added mapping for it on container creation with -v), and then it went fine, I didn’t even need to chown it to a different user.
One other thing to add here is that for nobody user I was getting this warning:
Special user nobody configured, this is not safe!
so I replaced User=nodoby with DynamicUser=yes in the /etc/systemd/system/docker-wol.service, and now it’s all perfectly splendid (unless there are other security-related problems with exposing named pipes, which I don’t yet know about).