Sbin folder isn't in `ubuntu` user's PATH

ubuntu@ubuntu-16-04-ssd:~$ echo $PATH

Anyone know why the sbin folders are missing in the PATH, and how to properly fix it?

This is a fresh created Ubuntu 16.04 container, and I logged in using lxc exec ubuntu-16-04-ssd -- su --login ubuntu


I get both /sbin and /usr/sbin in the $PATH, and I log in with

lxc exec mycontainer -- sudo --user ubuntu --login

The command you wrote has a typo. Can you verify that you type the command I wrote above?

I’m using the su command instead of sudo command, and I’m pretty sure the syntax is correct:

$ su --help
Usage: su [options] [LOGIN]

  -c, --command COMMAND         pass COMMAND to the invoked shell
  -h, --help                    display this help message and exit
  -, -l, --login                make the shell a login shell
  -m, -p,
  --preserve-environment        do not reset environment variables, and
                                keep the same shell
  -s, --shell SHELL             use SHELL instead of the default in passwd


The sudo command does loads into an environment with sbin PATHs, however I didn’t feel like using it simply due to “it works”.

I managed to replicate and indeed su --login ubuntu does not add the two sbin directories to the path.
Note that for this command to work, you would need to set a password for the ubuntu user account.

I think this is a su issue and it is expected behavior. With su --login ubuntu, you are asking for a login shell for a non-root user. The sbin directories have system binaries, therefore traditionally in Unix/Linux the default $PATH for non-root accounts does not have any sbins. Note that this is not a LXD issue. If you su --login root, you will get the sbin directories in the $PATH.

Also note that su --login does not read configuration files in /etc/profile.d/ so you get even less into your $PATH.

If the reason you want to use su --login is that sudo --user ubuntu --login is too long, then you can use an alias to make it shorter (lxc mycontainer ubuntu is what you type and you get the login shell).

1 Like

This is definitely not the case as you can still find /snap/bin in the PATH, which is defined in the profile.d, also echo "echo 'The profile.d works'" | sudo tee /etc/profile.d/ also shown that the profile.d is source’d as it should in a login shell.

root account is disabled in Ubuntu in the first place so this is probably not the criteria of inserting sbin dirs into the PATH. The default ubuntu user belong in the sudo group which is the default administrative user group in Ubuntu.

I agree, but the problem rises in this container so it’s quite worth to find out what actually causes it, the fact that Ubuntu’s sudo is problematic from the start makes it even worthier.

The root account in Ubuntu is not disabled. It is not meant to be logged in directly with a password. It is configured in such a way that you need to sudo from a non-root account. In this way, there is some information as to who started each root session.

You can trace why su --login does not add the sbin directories to the $PATH of the non-root user. My recollection is that it follows the Unix tradition of not adding system directories to the $PATH of non-root users.