Shell prompt regression after latest 19.0.0 update

[Cougar]

Problem/Motivation

Shell prompt is broken

Expected behavior

Prompt like this:
config #

Actual behavior

Prompt now
\[\e]0;\u@\h:\w\a\]\W $

Steps to reproduce

ssh to the home assistant

Proposed changes

No idea how zsh prompt works :(

[Greminn]

Confirmed seeing the same thing

[adrianrdzv]

Confirming, ssh not working after update. Seeing the same output.

[Johanneke]

I have the same issue:
\[\e]0;\u@\h:\w\a\]\W $ pwd /home/<user>

Edit:
actually, I used to do ssh <user>@<homeassistant> and would then have a prompt inside /home/root. But now I end up in /home/<user>.
If I then do sudo su - root the prompt is normal again.
So something with users/groups/roles?

[tsightler]

I believe it was broken by PR #755 which changed the default shell from /bin/sh to /bin/zsh for the added users. However, the script creates only .profile, while, I'm pretty sure that zsh will not run .profile by default for a login shell, and thus requires .zprofile to exist.

A temporary hack is to add the following to "init_commands" configuration option and restart:

ln -s /home/hassio/.profile /home/hassio/.zprofile

Note that if you use a username other than "hassio" you should replace that in the path above.

[craigccfl]

I have the same issue:
[\e]0;\u@\h:\w\a]\W $ pwd /home/

I'll be waiting for version 19.0.1 fix. Until then rolling back to version 18.0.0, which is working as expected. Thanks all

[tsightler]

@frenck I believe that PR #755 should be backed out, I can find no logical reason for the change and not sure why it was accepted. As far as I can tell previous behavior was:

1. User created based on username in configuration with default shell of /bin/sh
2. User logs in, /bin/sh is started as login shell, executes .profile containing command 'exec sudo -i' to start a root shell
3. Root shell is either /bin/sh or /bin/zsh based on configuration setting (modified during container startup).

Now, behavior is:

1. User created based on username in configuration with default shell of /bin/zsh
2. User logs in, /bin/zsh is started as login shell, .profile not executed because zsh doesn't execute .profile by default for login shells
3. User is left as regular user with /bin/zsh that is partially configured since there is no .zprofile

Fix options:

Back out PR #755, which is not required as /bin/sh is fine for login user since it will be immediately replaced by switch to the configured root shell.

--or--

If for some reason it is desired to have login user leverage /bin/zsh (I have no idea why) then I believe ssh/rootfs/etc/s6-overlay/s6-rc.d/init-ssh/run line 110 should be modified to create .zprofile instead of .profile.

I'm happy to provide a PR for either of this if needed, just not sure which is preferred.

[Cougar]

Maybe there is a good reason not to immediately sudo to root? Docker is not accessible but /config directory is readable. In this case the prompt needs to be fixed and new behavior documented.

I can confirm that running sudo -i in login shell restores the previous behavior.

I can understand the #755 reason as root shell is already zsh. In my opinion we should not go back to sh (busybox) but fix .profile problem. I'm not zsh user myself but it looks to me that this file needs just to be renamed to .zshrc.

[tsightler]

I can understand the #755 reason as root shell is already zsh.

But that's not true, rather, root shell is either /bin/zsh or /bin/bash based on whether config contains "zsh: true" or not, and since the only purpose of the ssh user being added is so that you can login with a username other than "root", it's not clear why it matters what shell this user leverages, since it will always just immediately be replaced by the configured root shell. IMO, using the Busybox /bin/sh makes 100% sense in this case because it's super fast to load and execute the profile and is then replaced a few milliseconds later.

Regardless, it's not my decision and I don't really care one way or another what the fix is, but that PR is what caused it to break. If that PR would have included an additional line that change .profile to .zprofile, it would be fine.

[Cougar]

Yes, root shell could be zsh too (when configured so), however root user has .zshrc file installed but hassio has still only .profile which is not used by zsh.

Of course it would be good to use the same shell configuration option for both accounts. It is anyway the same person who uses them.

[danielbrunt57]

My solution to get things back like they were before where my SSH session as hassio had correct PWD prompt & root privileges as well as SSH window scollback and copy/paste buffer:

Create /home/hassio/.zprofile with:

PROMPT='%d%>:%{\e[0m%}>> '

sudo visudo /etc/sudoers and uncomment # %wheel ALL=(ALL:ALL) ALL since hassio is a member of groups hassio and wheel :

## Uncomment to allow members of group wheel to execute any command
% wheel ALL=(ALL:ALL) ALL

Also, since some file perms might exclude the group wheel, I also added hassio to group root using this command (just to be sure): sudo /usr/sbin/addgroup hassio root.

/home/hassio> groups hassio
hassio root wheel

Ref: Add a User to a Group (or Second Group) on Linux
Note: busybox uses addgroup instead of Linux groupadd

[ViViDboarder]

It does indeed seem that #755 introduced a bug. It looks like default shell is being created as zsh, however, just below, there is attempt to run sudo -i on login via ~/.profile, which is unused by zsh. It appears that either the shell should be reverted or the file should be updated to echo to ~/.zprofile instead.

[pergolafabio]

ah, just found this thread, is it the reason why its showing some strange behaviour?

[N3rdix]

ah, just found this thread, is it the reason why its showing some strange behaviour?

Yes, as it's mentioned in the very first message of this thread 😉

[pergolafabio]

is that the reason why i cant do for example chmod? this worked before
i get operation not permitted now, on a .sh file i want to make executable
chmod 777 xxx.sh

[ViViDboarder]

Yes. This is because you are no longer root.

[ViViDboarder]

I've opened a PR to revert the change. The login user shell doesn't matter since the user is supposed to be immediately dropped to the root shell anyway. I'm not sure why it was thought to be a fix for #744.

[Eldarion85]

What is the reason to prefer zsh over bash? I deactivated the zsh option in the terminal settings and was then able to log in again with Putty or cmd without any problems and without the ugly characters in front of my input.
Can anyone tell me what disadvantages this has compared to zsh?

[pergolafabio]

indeed, its as easy as turning off "zsh" to have the old prompt back

[Eldarion85]

It's simple, but I'm probably not the first person to test the simple solution. Especially since the information that "bash" is used again after deactivation is even in the terminal documentation.
So my question was whether there is a disadvantage if I don't use zsh, or whether nobody has actually tested simply deactivating it :D.

[tsightler]

If you don't use any of the zsh features, such as much improved tab completion and command history, just as an example, then sure, not really any negatives, you can use whatever shell you want.

I still think adding a single line to the configuration, as I suggested above, is the easiest workaround to get back to original behavior with a working zsh (I much prefer zsh interactive behavior to bash) but there are plenty of options.

[ViViDboarder]

Without the patch being reverted, disabling zsh replaces zsh with bash for both the root and new user, thereby resolving the issue. Yes.

However, if you do use zsh, then this issue remains. Additionally, the issue is not so much the prompt, but that you are not running as the root user, which is what this addon assumes to be true.

As such, reverting the PR should be done as a quick fix or adding a zprofile and testing that.

I'm working around this by adding echo "exec sudo -i > "/home/$(bashio::config 'ssh.username')/.zprofile" to a script that I run on addon start.

Incidentally, I actually use fish, so I also have apk add shadow && chsh -s $(which fish) in that script.

[kinghat]

turning off zsh in the config still doesnt allow me permissions to edit files in vscode. unless im missing something. can this be reverted to previous functionality please?

[oywino]

Any news of a 19.0.1 release to fix things?

[ViViDboarder]

There's a patch. Just needs a review. Frenck maintains a lot of repos, so it may take some time for him to turn his attention here.

In my oppinion, the simplest fix is what @tsightler posted above:

A temporary hack is to add the following to "init_commands" configuration option and restart:

ln -s /home/hassio/.profile /home/hassio/.zprofile

Note that if you use a username other than "hassio" you should replace that in the path above.

[rct]

@Cougar I suggest renaming this issue now that it is better understood to be more than just a prompt issue. Maybe something like:

Change to zsh in #755 breaks running .profile preventing sudo to root

I also think @tsightler solution seems like a good one if not the best. Rather than revert #755, there just needs to be an equivalant profile that Zsh or other shells would run.

The docs/readme should probably be updated to mention that whenf you change shells you need to make sure that sudo to root happens.

[oywino]

I agree with @tsightler - this change should not have been approved. Just because a contributor has a preference for something fancy (that no one else has even heard about), even for all the good reasons, it cannot be allowed to be forced upon everyone else. Even if a workaround exists, most of us "common mortals" will end up spending days in vane trying to figure out what's gone wrong.

[rct]

Thanks to this issue I finally understand why I've seen strange behavior with ssh commands and rsync using this add-on.

The add-on's intended behavior seems to be that you ssh in as hassio (a non-root user) and then /home/hassio/.profile implicitly turns you into the root user inside of the container. The dot files the user normally sees like .zshrc are under /root/

Problems arise if you change shells or use ssh to run a non-interactive like ssh hassio@homeassist 'id;pwd'. Those commands will not be run as root in the container since .profile doesn't get evaluated. So for example rsync will encounter permission issues until you realize the issue.

Another example that fails in a surprising way:

$ ssh hassio@hass 'cd /config && git status'
fatal: detected dubious ownership in repository at '/homeassistant'
To add an exception for this directory, call:

        git config --global --add safe.directory /homeassistant

Once you know, you can work around that with sudo:

ssh -A hassio@homeassistant 'cd /config && sudo git push

(That's useful if you don't want to maintain unprotected ssh credentials inside of hass)

So, rather than revert #755 as a solution, maybe there should be a less brittle way of becoming the root user that will work with all shells and non-interactive sessions?

[ViViDboarder]

I agree that the mode of user switching (or why even use root?) should be addressed in longer term, however it seems prudent to revert and fix the regression.

[rct]

(or why even use root?)

Currently with HaOS everything in config (and elsewhere) is owned by root. Here's the view from the host os (not the container)

# ps -ef | grep python
root       33633   33632  0 Oct24 ?        00:39:48 python3 -m supervisor
root      247993  247483  0 Sep24 ?        08:01:11 /usr/bin/python3 /usr/bin/appdaemon -c /config -D INFO
root     1565764 3668601  0 22:14 pts/6    00:00:00 grep python
root     2006605 2005933  0 Oct29 ?        00:11:45 /usr/bin/python3 /usr/local/bin/esphome dashboard /config/esphome --socket /var/run/esphome.sock --ha-addon
root     3683299 3683297  1 Nov02 ?        01:20:35 python3 -m homeassistant --config /config


# cd /mnt/data/supervisor/homeassistant/
# ls -l automations.yaml scripts.yaml configuration.yaml home*
-rw-r--r--    1 root     root           591 Oct 17 19:49 automations.yaml
-rw-r--r--    1 root     root           814 Jun  9 18:40 configuration.yaml
-rw-r--r--    1 root     root         23926 Nov  5 15:34 home-assistant.log
-rw-r--r--    1 root     root        179664 Nov  2 19:04 home-assistant.log.1
-rw-r--r--    1 root     root         27509 Mar  4  2024 home-assistant.log.fault
-rw-r--r--    1 root     root     143912960 Nov  5 22:10 home-assistant_v2.db
-rw-r--r--    1 root     root         65536 Nov  5 22:16 home-assistant_v2.db-shm
-rw-r--r--    1 root     root       4738032 Nov  5 22:16 home-assistant_v2.db-wal
-rw-r--r--    1 root     root           456 Jul 18  2023 scripts.yaml

# find . ! -user root
#

[danielbrunt57]

I agree with @tsightler - this change should not have been approved. Just because a contributor has a preference for something fancy (that no one else has even heard about), even for all the good reasons, it cannot be allowed to be forced upon everyone else. Even if a workaround exists, most of us "common mortals" will end up spending days in vane trying to figure out what's gone wrong.

I concur! In 30+ years using UNIX (10+ years Linux) I never had a need or desire to use zsh. I always used the defacto standard sh or ksh. Don't force me to use something newer! If I want to continue using my rotary dial telephone then let me!

[ViViDboarder]

The thing is, merits of default shell aside, changing the shell of the authentication user should not even be required as the first thing that happens when you auth with that user is that you su back to root. So there is no reason that shouldn't just be sh ever. Even if someone prefers zsh.

[ViViDboarder]

(or why even use root?)

Currently with HaOS everything in config (and elsewhere) is owned by root. Here's the view from the host os (not the container)

Interesting. Yea, I figured it probably had to do with permissions in the config dir. It probably goes beyond the scope of this addon, but if group had rw, then the ssh user could be added to the group and be permitted access.

I suppose this is getting off topic though...

[rct]

The thing is, merits of default shell aside, changing the shell of the authentication user should not even be required as the first thing that happens when you auth with that user is that you su back to root. So there is no reason that shouldn't just be sh ever. Even if someone prefers zsh.

True, particularly since the .profile exec's sudo -i so there isn't a concern over memory footprint.

Regardless the main concern is something Frenck (or anyone else with merge/release permissions) will accept.

[ssbarnea]

I like zsh and have no problem with it,... when is working. So far the default setup is broken and the only workaround I found was to add a custom init command to the config, one that has the full path to my user home directory included:

ln -f -s /home/xxx/.profile /home/xxx/.zprofile

Note that use of $HOME or ~ did not work. I hope to see this sorted soon.

[DrShivang]

same issue

using the solution posted by @tsightler for the time being.

I believe it was broken by PR #755 which changed the default shell from /bin/sh to /bin/zsh for the added users. However, the script creates only .profile, while, I'm pretty sure that zsh will not run .profile by default for a login shell, and thus requires .zprofile to exist.

A temporary hack is to add the following to "init_commands" configuration option and restart:

ln -s /home/hassio/.profile /home/hassio/.zprofile

Note that if you use a username other than "hassio" you should replace that in the path above.

[mbonsack]

The problem with the symlink hack is that it will not survive a full shutdown. (Settings --> System --> 1/0 button upper right --> Advanced Options --> Shutdown System).

This will have to be fundamentally addressed by the developer. I personally love zsh and would like to see it remain as a shell choice, but unfortunately any home directory changes are wiped on a shutdown (as it's a container).

add a custom init command to the config

@ssbarnea where, specifically, did you do this? Perhaps this will solve the shutdown wipe.