User & permissions weirdness openhab vs openhabian

Setup, Configuration and Use Migration
1

Hi,

I have some string things going which I noticed now that I’ve upgraded to OH 3.0

I have 2 users
1.) openhab:openhab
2.) openhabian:users

but only /home/openhabian exists. When I log-in through SSH I am also logged in as openhabian.

When I check comments in /etc/passwd it says that “openhab:openhab” is the runtime user.

The point is when I run “Fix Permissions” in openhab-config I get the following errors:

2021-01-26_17:19:01_CET [openHABian] Applying file permissions recommendations... FAILED (openhabian chown /home/openhabian)
FAILED (mosquitto passwd permissions)
FAILED (mosquitto log permissions)
OK
OK
OK
OK
FAILED (openhab log)
OK

Moreover when I start sudo openhabian-config I get the following error:

2021-01-26_17:17:51_CET [openHABian] Loading configuration file '/etc/openhabian.conf'... FAILED (add default usergroup openhabian)

I already tried changing ownerships on my on for example everything in /home/openhabian to specific user and groupd (because some files were root:root) but I still get the error. So what do I need to do to fix this cause I don’t even know what is know exactly when when I get this “FAILED (xyz)”

Thanks for any insights.

2

openhabian is normally member of the group openhabian and openhab.
It looks like you did it in an other way.
This seems to be the reason for the meassage when you run it with sudo privileges.
Fix this first.
Seondly it sounds like you do not start openhabian-config with sudo privs which is required.
You can’t login via ssh as user openhab as the user openhab does not have a shell in a normal openhabian-config installation resp. OH installation.

3

Only openhab itself runs as user openhab (which is always there), the remaining tools will use as user AND group what you specified in /etc/openhabian.conf as the “username”, usually openhabian that is.

As to why some commands fail I suspect too you forgot to sudo. Set debugmode=maximum and you’ll see the commands that fail.

4

Hi @Wolfgang_S,

Thanks for the tipps on users & groups. I fixed the users & groups for openhabian. Now all of the errors (also loading config file on startup) except 1 are gone.

@mstormi
I’ve set debugmode=maximum and I see that the following is failing, see comments below

$ fix_permissions /etc/mosquitto/passwd mosquitto:openhabian 640 750
+ fix_permissions /etc/mosquitto/passwd mosquitto:openhabian 640 750
+ [[ -e /etc/mosquitto/passwd ]]
+ chown mosquitto:openhabian /etc/mosquitto/passwd
+ [[ -n 640 ]]
+ find /etc/mosquitto/passwd -type f -print0
+ xargs -0 chmod 640
+ [[ -n 750 ]]
+ find /etc/mosquitto/passwd -type d -print0
+ xargs -0 chmod 750
chmod: missing operand after ‘750’
Try 'chmod --help' for more information.
+ return 1
+ return 1
+ echo 'FAILED (mosquitto passwd permissions)'
FAILED (mosquitto passwd permissions)
+ retval=1
+ cond_redirect fix_permissions /var/log/mosquitto mosquitto:openhabian 644 755
+ [[ -n '' ]]
+ echo -e '\n\033[90;01m$ fix_permissions /var/log/mosquitto mosquitto:openhabian 644 755 \033[39;49;00m'

It seems the scripts checks either for file /etc/mosquitto/passwd (which exists in my case) and sets it’s permissions to 640 which it did. And then it also checks for /etc/mosquitto/passwd as a directory? of course the second find command does not return anything hence the xargs -0 chmod 750 fails then.

I must say that I’m no expert in shell scripting but this looks like one of the two conditions will fail always either the file or the directory condition. Is this a bug? Cause it’s quite strange if you don’t turn on debug logs and ist just says FAILED (mosquitto passwd permissions) then you think something is wrong with your setup. I’m currently using openhabian-config from stable OH3.0

Can you please elaborate on this a bit? Thank you

5

There is no such thing. The openHABian stable branch is for OH2.

According to your Github issue you use Ubuntu on some unsupported hardware.
I’ll take this hint but from now on please mention upfront on posts and don’t address future requests to myself, I will not be providing support for anything Ubuntu.
And to make that clear: that sort of providing support already starts with having to read about potential issues. So please don’t raise any unless you have seen it happen on a supported system.

You issue is complicated, I’ll provide a fix. But ultimately nothing’s wrong, it is just a cosmetical error.

6

I had the same problem, every time I tried to fix permissions, I had problems. I found that reinstalling Mosquitto, this time without password (just Enter) and then fix permissions, the problem is solved. Please try it.

Cheers.

1 Like
7

Had the same problem. Removing the password from Mosquitto > run fix permissions > set Mosquitto password.

Looks like a bug in Openhabian.

8

If you think it’s a bug then open a Github issue and provide a more careful description and up to date debug logs.
Note Ubuntu is unsupported (so anything not working there cannot be a bug).

9

For me it’s not possible to open a Github issue, sorry.

I’m just running on Rpi4b with the latest openhabian image with a SSD, pretty default I guess.

Best thing I can do is describe what went wrong on my side (as Marc Elser perfectly did), and hoping someone would create such an issue.

On my system there was something wrong with the permission rights on certain folders for grafana, my own fault, i did something wrong. so Grafana wouldn’t start because it couldn’t reach it’s files. Couldn’t remember what chmod it should be. So for a quick sollution I used the Fix permissions and it gave the error: [FAILED (mosquitto passwd permissions)]. Changed the password to none, permissions set > Tried again and grafana worked. Thought it was strange behaviour in openhabian-config so I gave it a search here. Found this thread, confirmed what I was thinking.

So I think it couldn’t be anything else than a bug, but maybe i’m wrong, no clue i’m not a developer don’t attack me on my lack of knowledge.

I understand not everything is fixable due to shortage of time or interest, that’s no problem and no one should make a problem of that. But at the other side, not all users want to dive in every problem deeply (that’s how it feels to open a github issue). We just want to use and enjoy openhab and discuss about it at this forum. Openhab is a very maintenance intense system on it’s own, even without it’s bugs. If I would maintain every bug I have found on github, I wouldn’t be able to have a regular 40 hour job :wink: .

10

No, SSD is not default at all.

why not, anyone can.

Now come on. There’s people to spend their spare time to develop so you can use this for free, and you’re not even willing to contribute some minutes although you could at that stage ?
We (developers) need you (users) to do the testing/debugging as it only happens on your systems.

Read the debug guide to get to know what to do and as I already said, craft a careful description of the buggy behavior, reproduce it with logging on and provide it as a Github issue.

11

Don’t get me wrong, I really appreciate what you guys do and when I have the time I’m willing to help (as I do from time to time) but not with every problem, sorry.

For my situation, I have to stop grafana, corrupt the folders/files with wrong rights, read the documentation how to debug, hoping the problem will occur (has to be), log the problem, correct the problem, (log again?), open a issue in GitHub, make a clear description what happend, and maybe other stuff I forget. As a side note, I have trouble stopping and starting openhab service on my system, my Google Voice gets corrupted (hear only white noise via 3.5mm Jack) for some reason and I have to clear cache, restart in random order etc for it to get it to work, is not consistent unfortunately. That’s also a reason why I am holding back a little. That all is not a couple of minutes work.

I only added my info, so other users would know this is an issue other have too.

For me, this doesn’t require a fix. The above solution is a fix for me. I understand not every system is the same but I think it’s strange this problem doesn’t happen on any system (with mosquito having a password).

By the way, the difference between a SD card and an SSD in practical use isn’t that big, that’s why I think it’s pretty default :slight_smile:

12

I have the same problem ob a PI4 which does not have an SSD. I recently upgraded to OpenHAB3, but I don’t know if it worked before the upgrade, as there was no reason to call “Fix permissions” in openhabian-config.

$ fix_permissions /etc/mosquitto/passwd mosquitto:openhabian 640 750 
+ fix_permissions /etc/mosquitto/passwd mosquitto:openhabian 640 750
+ [[ -e /etc/mosquitto/passwd ]]
+ chown mosquitto:openhabian /etc/mosquitto/passwd
+ [[ -n 640 ]]
+ find /etc/mosquitto/passwd -type f -print0
+ xargs -0 chmod 640
+ [[ -n 750 ]]
+ find /etc/mosquitto/passwd -type d -print0
+ xargs -0 chmod 750
chmod: missing operand after ‘750’
Try 'chmod --help' for more information.
+ return 1
+ return 1
+ echo 'FAILED (mosquitto passwd permissions)'
FAILED (mosquitto passwd permissions)
+ retval=1
+ cond_redirect fix_permissions /var/log/mosquitto mosquitto:openhabian 644 755
+ [[ -n '' ]]
+ echo -e '\n\033[90;01m$ fix_permissions /var/log/mosquitto mosquitto:openhabian 644 755 \033[39;49;00m'
13

The problem here might be that the value passed to the first parameter of fix_permissions is not a directory but a file:

/etc/mosquitto/passwd

Therefore, the following command doesn’t find anything:

find /etc/mosquitto/passwd -type d -print0

And the following command fails due to a lack of arguments:

xargs -0 chmod 750
14

State at least the minimum needed to help you, version and branch of openHABian these are.
Explain how you upgraded.

15

openHAB console states “3.0.1 - Release Build” when logging in.

openHABian Configuration Tool [stable]patchday-20210119-1116(5e807c0)

grafik
grafik967×322 37.3 KB

For whatever reason, option 01 (“Select Branch”) states, that currently the stable openHAB 2 is being used.
grafik

For the upgrade, I used option 03 (“Install openHAB”) - as explained here:

16

Switched to openHAB3:

grafik
grafik960×319 34.5 KB

The error still remains, but the log is slightly different:

$ fix_permissions /etc/mosquitto/passwd mosquitto:openhabian 640 750 
+ fix_permissions /etc/mosquitto/passwd mosquitto:openhabian 640 750
+ [[ -e /etc/mosquitto/passwd ]]
+ chown mosquitto:openhabian /etc/mosquitto/passwd
+ [[ -n 640 ]]
+ [[ -f /etc/mosquitto/passwd ]]
+ find /etc/mosquitto/passwd -type f -print0
+ xargs -0 chmod 640
+ [[ -n 750 ]]
+ [[ -d /etc/mosquitto/passwd ]]
+ return 1
+ echo 'FAILED (mosquitto passwd permissions)'
FAILED (mosquitto passwd permissions)
+ retval=1
+ cond_redirect fix_permissions /var/log/mosquitto mosquitto:openhabian 644 755
+ [[ -n '' ]]
+ echo -e '\n\033[90;01m$ fix_permissions /var/log/mosquitto mosquitto:openhabian 644 755 \033[39;49;00m'

As you can see, the fix_permissions function does not call

find /etc/mosquitto/passwd -type d -print0

any more - probably because it now it first checks if it is a directory - see:

But it still returns 1 which means FAILURE.

From my current understanding, if the first parameter is a file, either the caller should omit the fourth parameter or fix_permissions should ignore the fourth parameter and return 0 (=SUCCESS).

17

There’s another fix_permissions call which does not work on my system:

$ fix_permissions /opt/zram/log.bind/openhab openhab:openhabian 664 775 
+ fix_permissions /opt/zram/log.bind/openhab openhab:openhabian 664 775
+ [[ -e /opt/zram/log.bind/openhab ]]
+ return 0
+ return 0
+ echo 'FAILED (openhab log on zram)'
FAILED (openhab log on zram)
+ retval=1

On my system, the folder /opt/zram/log.bind does not exist. The folder /opt/zram does exist.

18

Yes it should return 0 but it’s neither of these. I fixed it in main.

That’s totally unrelated, don’t mix issues please.

19

Yes, indeed. With your bugfix applied, the error does not occur on the file /etc/mosquitto/passwd any more:

$ fix_permissions /etc/mosquitto/passwd mosquitto:openhabian 640 750 
+ fix_permissions /etc/mosquitto/passwd mosquitto:openhabian 640 750
+ [[ -e /etc/mosquitto/passwd ]]
+ chown mosquitto:openhabian /etc/mosquitto/passwd
+ [[ -n 640 ]]
+ [[ -f /etc/mosquitto/passwd ]]
+ find /etc/mosquitto/passwd -type f -print0
+ xargs -0 chmod 640
+ [[ -n 750 ]]
+ [[ -d /etc/mosquitto/passwd ]]
+ return 0
+ return 0
+ cond_redirect fix_permissions /var/log/mosquitto mosquitto:openhabian 644 755
+ [[ -n '' ]]
+ echo -e '\n\033[90;01m$ fix_permissions /var/log/mosquitto mosquitto:openhabian 644 755 \033[39;49;00m'

Thanks for fixing this.

20

I have a question related to this: I am trying to start a script external to OpenHAB by starting it from inside an OH Osgi component by instantiating a ProcessBuilder with the command line below…

sudo -k -u "openhabian" -S <<<"password" /bin/bash -c ./myscript.sh

But unfortunately sudo does not start the script, and instead reports an error with the famous “We trust you have received the usual lecture” lecture and a prompt for [sudo] password for openhab. – Nota Bene the prompt refers to the PW for the user ‘openhab’ whereas the sudo command line is to execute for the user ‘openhabian’ !!

So can someone please advise why a sudo call for ‘openhabian’ results in an error prompt for ‘openhab’? I guess that as the OH module is running under ‘openhab’, the ProcessBuilder command is somehow constrained to allow only ‘openhab’ as a user, and even though the script is trying to break out as ‘openhabian’ user, it is blocked in some way. Or something like that?

Anyway, perhaps someone can give me a tip about how to break out from within ‘openhab’ to the wider ‘openhabian’ user?