Bash script works ok from SSH Terminal, not when used as shell_command service in HASS.IO

Installation Home Assistant OS
1

My HASSIO (v.0.76.0) docker container is running happily on an Intel NUC, with Ubuntu Server 18.04 as base OS.

Because the lovely Dropbox Sync add-on (made by Daniel Welch) is not working for me (and others), I want to run the underlying dropbox_uploader.sh script as a shell_command service.

Therefore, I copied the script and .dropbox_uploader file to the location where I land when SSH-ing into HASSIO. The file is containing the credentials when you run it for the first time.
It needs to be on a location that is persistent after a reboot, else you need to provide the credentials every time you run it.

However, I do run into an issue when trying to run the command as a shell_command service.
The command itself works ok when I run it in a SSH Terminal.

./dropbox_uploader.sh -f .dropbox_uploader -s upload /backup/*.tar "/hassio/"

I added the following shell_command to my configuration.yaml to be able to call it as a service.

shell_command:
  dropbox_uploader: '/bin/bash ./dropbox_uploader.sh -f  dropbox_uploader -s upload /backup/*.tar "/hassio/"'

When calling the service, it fails with the following error in the log:

ERROR (MainThread) [homeassistant.components.shell_command] Error running command: `/bin/bash ./dropbox_uploader.sh -f .dropbox_uploader -s upload /backup/*.tar "/hassio/"`, return code: 1 NoneType: None

I tried several ways to write the command in the configuration, with and without ‘…’, with and without /bin/bash in front of it. Etc…

Searching did not provide me with a solution however, I tried everything that was suggested. Also found one very similar thread with the same behavior with no follow up or solution.

I am a little lost here, any suggestions?

2

Use the full path to the script file - eg /config/dropbox_uploader.sh and if -f is for a file, use the full path to that file too.

1 Like
3

Thanks for your suggestion. While Googling on that error before I quickly found out it is related to the path/location of the script.
I have tried using the path, before I moved the script to the location were I land when SSH-ing to the container (to test if not having it some other path would solve the issue).

But still the same behavior and error (sometimes it is a 127 return code i.s.o. 1).

Running it manually in a SSH Terminal it works OK using those paths but not when using the shell_command service.
I have found a lot of examples of variations using SSH and a key pair to run Bash scripts on other nodes, but I stay local so should not be needed.

4

dropbox_uploader%20bash%20output
dropbox_uploader%20bash%20output1463×926 184 KB

Tried some more and used the absolute paths from root up to the files and adding an error output to a file (2> /config/command.log), no luck.

As you can see in the screenshot of the SSH Terminal, manually executing the script still works OK. Both from SSH landing location (~) and up to root (/) (e.g. not the /root directory).

When calling the service (using the exact same shell_command) from within HASSIO, the command.log error output file shows:

/bin/bash: /root/config/dropbox_uploader.sh: No such file or directory

BTW, both script and config files are also in the /config directory (the screenshot shows them in the ~ directory. Before someone smart mentions the path is wrong…
:wink:

It also should be run using /bin/bash, see the shebang in the script :
#!/usr/bin/env bash

5

Well no, because for some reason you’re using ~/config/ rather than /config/

6

Was not working without the ‘~’ in front of the path, I tried that as well using /config/dropbox_uploader.sh.

Strange though that the exact same command works perfectly when run in the shell itself?
Tested it with /root/config/dropbox_uploader.sh --> nope…

Current in my configuration.yaml:

shell_command:
  dropbox_uploader: /bin/bash /root/config/dropbox_uploader.sh -f /root/config/.dropbox_uploader -s upload /backup/*.tar "/hassio/" 2> /config/command.log

The output when running the script with that command in the shell:

https://hastebin.com/jiwarameze.shell

Calling the shell_command in HASSIO:

2018-08-20 21:32:38 ERROR (MainThread) [homeassistant.components.shell_command] Error running command: `/bin/bash /root/config/dropbox_uploader.sh -f /root/config/.dropbox_uploader -s upload /backup/*.tar "/hassio/" 2> /config/command.log`, return code: 127

command.log shows:
/bin/bash: /root/config/dropbox_uploader.sh: No such file or directory

[EDIT]

And the output using /config/dropbox_uploader.sh:

https://hastebin.com/hoxozudani.shell

2018-08-20 21:55:46 ERROR (MainThread) [homeassistant.components.shell_command] Error running command: `/bin/bash /config/dropbox_uploader.sh -f /config/.dropbox_uploader -s upload /backup/*.tar "/hassio/" 2> /config/command.log`, return code: 1

command.log is somehow empty…

7

Couple things…why do you run it as root? Not sure if hass.io works differently than Rasbian or Ubuntu but…
this works for me on both environments (the last two). I have the whole Dropbox-Uploader directory in /home/homeassistant

upload_kitchen2_motion: '/home/homeassistant/Dropbox-Uploader/dropbox_uploader.sh upload /home/homeassistant/*.mp4 uploadvid/'

I don’t need to use /bin/bash

8

It is a HASS.IO thing, mapping and setup of directories is not like the normal home assistant. For instance, the /www directory is only reachable as /local.
We do not have a ‘home’ folder. You only can access it as root.

And because that is a mapping I am sure of exists, I have tested putting the script files in there and use the path to that directory as well, but no luck either.

Thanks for your suggestions though.

According to Portainer (to manage Docker containers), the mapping of the homeassistant container is:

Host/volume Path in container
/usr/share/hassio/homeassistant /config
/usr/share/hassio/ssl /ssl
/usr/share/hassio/share /share

Of course I tested this path now I found it…
But, you guessed it probably by now, result:

/bin/sh: /usr/share/hassio/homeassistant/dropbox_uploader.sh: not found

Maybe I need to SSH to the host to be able to run the shell_command?

9

hey, did you ever figure it out? i also have those errors 1 and 127 , running from ssh works though
also running hassos here , struggling with paths also, i dont know why it works from ssh, but not from a service

10

Hi Fabio. No, I have since then moved to another solution for backup (Google Drive) running on a different hardware/OS setup altlogether. Never had the need to run scripts since.

11

yeah, is strange, my other bash scrips are working this one not , my guess is that i am using an “apk add” command, it doesnt like it i think, maybe needs sudo access

thnx anwyay :slight_smile:

12

Theres a pretty limited set of commands you can use. It will be running in the Home Assistant container when you run a shell command. If you open a console in that container and try and run the script you will see what is causing the problem.

13

my yaml code is fine, if my bash script is like :

#!/bin/bash
echo abc > abc.txt

the file is created, so that means all yaml code is good! also shell command is fired

when the bash script is like below , i receive error 1 or error 127
if i do the same apk command or the same /bin/bash /config/bash.sh from PUTTY/SSH it also works
so my guess its the HA user doesnt have the right to use the APK ADD command

#!/bin/bash
apk add can-utils

return code: 1

############

#!/bin/bash
sudo apk add can-utils

return code: 127

14

Did you even read what I posted to you?

15

How can I open a console in that container?

16

either via docker exec or use portainer

1 Like
17

it indeed gives an error there, the command works though

any idea what that means?

image

18

Ok, i know why, i just need to point another release, seems there is a different version for Alpine edge and Alpine 3.13 and HA doesn’t allow community packages

1 Like
19

Same here, always 127 error, I’ve gone through a lot posts like this one, tried all paths possible, it simply doesn’t work.

In the past I’ve used HA with Python venv and worked perfectly. Now with HASS.IO my scripts and shell commands just fail without an usefull message.

20

Yeah, problem is that I’d you run it from a script, it actually fires in the HA container, and you don’t see the output… In the ssh addon, the command worked for me, but not in script, so I that I did, within the ssh addon, I do the docker command to enter the HA container, from there I do the command again, to see what error 127 was, so that’s how I resolved it…

In my case I was installing an APK alpine package, but the HA container was not able to find the repository for that specific APK, seems that container was another alpine version then the SSH container, so I pointed the APK file manually

Solved

1 Like