signal-cli-rest-api: Version 0.30 is not working

I have upgrade to the latest version and now it is not working anymore.

The log files show the following error:

+ set -e
+ chown 1000:1000 -R /home/.local/share/signal-cli
+ cat
+ exec setpriv --reuid=1000 --regid=1000 --init-groups --inh-caps=-all signal-cli-rest-api
setpriv: libcap-ng is too old for "all" caps

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 23 (18 by maintainers)

Commits related to this issue

fix "setpriv: libcap-ng is too old for 'all' caps" error query available capabilities instead of using "all" caps, as this fails with kernel 5.9.0 see #46 — committed to bbernhard/signal-cli-rest-api by bbernhard 3 years ago
fix "setpriv: libcap-ng is too old for 'all' caps" error query available capabilities instead of using "all" caps, as this fails with kernel 5.9.0 see #46 — committed to nomer/signal-cli-rest-api by bbernhard 3 years ago

Most upvoted comments

My main system is x86 Debian 10 stable with kernel 5.9.0-0.bpo.2-amd64 similar to @gadric. Just for reference, I just tested version 0.30 on a Raspberry Pi (for sure the right version this time!) with Home Assistant OS 5.9, the add-on works fine on that architecture/kernel.

Cool, thanks! That narrows it down a bit. So hopefully with a 5.9 kernel I should be able to reproduce the issue. 🤞

bbernhard on Jan 5, 2021

Ok, the latest tag should now updated 😃

One last issue that I ran into, changing ownership of the state file does not appear to be enough.

What do you mean exactly by state file? Do you mean the “+xxxx” file inside the data directory where signal-cli stores its config?

If so, then I am struggling a bit to understand why this is necessary in your case. Afaik the only difference between between 600 and 660 is, that with the former only the owner of the file can read/write the file whereas with the latter the owner and group members can read/write the file. But with chown 1000:1000 -R /data/data everything inside the data/data directory should have it’s owner changed. So even if the file has permission 600 it should work, no? thinking

Unfortunately, I can’t reproduce the issue here on my system (I am not using the HA addon though). Maybe the HA addon behaves somehow different here?

Yeah, I don’t really understand it, and I do mean the +xxxx file. I tried several iterations cloning the file from my production instance each time. The only combo that worked was the chown that is in your entry point file (pointing insted to /data/data) and then changing permission to 660. The default permission had been 600. When the permission is 600 the container log shows that the rest api was queried but no message is sent. No error though. As soon as I go to 660 the messages send again.

I will inject the chmod into the entrypoint in the add-on, it can’t hurt anyway.

The HA addon is not much different from your container. All I do is redirect the storage location of the state file and expose /data as a volume.

haberda on Jan 8, 2021

Updated to the latest version. Works! Perfect! Thank you a lot

gadric on Jan 8, 2021

My main system is x86 Debian 10 stable with kernel 5.9.0-0.bpo.2-amd64 similar to @gadric. Just for reference, I just tested version 0.30 on a Raspberry Pi (for sure the right version this time!) with Home Assistant OS 5.9, the add-on works fine on that architecture/kernel.

haberda on Jan 5, 2021

Hey @bbernhard I am having the same issue with the HassIO add-on. Looking back at what I ran when I tested it, it looks like I messed up and copied and launched the wrong Dockerfile, so I did’t actually test the dev container. Sorry about that. For now I will roll back the add-on. Thanks!

haberda on Jan 5, 2021

No problem. Dont worry. let me know when I can test 😄

gadric on Jan 5, 2021