$ su -
# echo $PATH
# exit
$ su
# echo $PATH

I have no idea why /bin and /sbin are not added to $PATH, if I do the plain su. This used to be the case. How can I fix this? I did notice that:

-rw-r--r-- 1 root root 0 Jan  8  2018 /etc/environment

But otherwise my system seems normal.

EDIT: I forgot the obligatory uname -a

Linux rpi3 4.17.0-1-arm64 #1 SMP Debian 4.17.8-1 (2018-07-20) aarch64 GNU/Linux


$ cat /etc/issue
Debian GNU/Linux buster/sid \n \l

all of the packages are from the "testing" repo, since "stable" ones don't work very well on aarch64.

  • I see /bin in both of your examples. you you say “I have no idea why /bin … are not added to $PATH” Commented Aug 6, 2018 at 9:03
  • Considering your kernel, that means you're not using only Debian stable. YOu absolutely have to add the result of this command: dpkg -S $(which su) and dpkg -l packagefromresult to know its version
    – A.B
    Commented Aug 6, 2018 at 9:15
  • Also please state if using stretch/stable, buster/testing or sid/unstable overall
    – A.B
    Commented Aug 6, 2018 at 9:21

2 Answers 2


Very recently (with version 2.32-0.2 of util-linux from 27 Jul 2018) Debian switched to a different su implementation, see bug 833256. The "new" su is from util-linux while the "old" one was contained in the login package and originated from src:shadow

Quoting from util-linux/NEWS.Debian.gz:

The two implementations are very similar but have some minor differences (and there might be more that was not yet noticed ofcourse), e.g.

  • new 'su' (with no args, i.e. when preserving the environment) also preserves PATH and IFS, while old su would always reset PATH and IFS even in 'preserve environment' mode.
  • su '' (empty user string) used to give root, but now returns an error.
  • previously su only had one pam config, but now 'su -' is configured separately in /etc/pam.d/su-l

The first difference is probably the most user visible one. Doing plain 'su' is a really bad idea for many reasons, so using 'su -' is strongly recommended to always get a newly set up environment similar to a normal login. If you want to restore behaviour more similar to the previous one you can add 'ALWAYS_SET_PATH yes' in /etc/login.defs.

The previously used su implementation behaved differently regarding PATH. This is also discussed in this bug report, see 833256#80. The new su preserves PATH if not invoked with su -.

In short: Debian's old su behaved like su -, at least regarding PATH. With the new implementation you should almost always use su -, similar to other distributions.

  • Considering the OP added: 4.17.0-1-arm64 as kernel, OP should really state the precise Debian version used and the precise package providing /bin/su, because with this kernel it appears the util-linux implementation might be in use (thus making my answer less useful)
    – A.B
    Commented Aug 6, 2018 at 9:12
  • Isaac: True, however I never stated that this is the current default. @A.B: Also true. Kernel 4.17 is currently only used in testing (upcoming release "buster" aka Debian 10) and unstable, both are currently very close to each other.
    – scai
    Commented Aug 6, 2018 at 9:51
  • @scai I use testing as it is the only repo I could get to work with aarch64 on a raspberry pi 3. Commented Aug 6, 2018 at 15:18
  • It might be also useful to note that the new su will read PATH env var from /etc/environment overriding anything set in etc/login.defs. Took me a while to find it ...
    – Mr.Coffee
    Commented Jun 10, 2020 at 10:35

The Debian su manpage tells:

The current environment is passed to the new shell. The value of $PATH is reset to /bin:/usr/bin for normal users, or /sbin:/bin:/usr/sbin:/usr/bin for the superuser. This may be changed with the ENV_PATH and ENV_SUPATH definitions in /etc/login.defs.

Quoting from /etc/login.defs:

# Three items must be defined:  MAIL_DIR, ENV_SUPATH, and ENV_PATH.
# If unspecified, some arbitrary (and possibly incorrect) value will
# be assumed.  All other items are optional - if not specified then

On a normal Debian system the variables are defined in/etc/login.defs :

# *REQUIRED*  The default PATH settings, for superuser and normal users.
# (they are minimal, add the rest in the shell startup files)
ENV_SUPATH      PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ENV_PATH        PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Testing by commenting out ENV_SUPATH reproduces partially your problem: su will not have /sbin (nor /usr/local/bin) while su - will execute the login script /etc/profile which will redefine PATH as expected for the root user.

So you should check for any alteration of /etc/login.defs and correct it, or see if an other part alters the PATH later (like a shell startup script such as some non-login bashrc script)

  • my ENV_SUPATH is exactly as you present it, but plain su produces $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games Commented Aug 5, 2018 at 9:44
  • that probably means you're in the second case: a global bashrc script (or any other unsuspected script) doesn't check for uid 0 before choosing PATH (like the id -u -eq 0 check done in /etc/profile for the su - case). If you suspect something special done recently on your system you should add it in the question.
    – A.B
    Commented Aug 5, 2018 at 9:46
  • it's very puzzling to me, that's why I asked the question. I see the check for uid 0 in /etc/profile, but still there is the abnormal $PATH Commented Aug 5, 2018 at 9:48
  • I'd run a quite wide inotifywait -r -m /etc /root /home/myuser > /tmp/list (or wider) , run su and look for a suspect in the results from /tmp/list. Also check selinux/apparmor if you're not using su from a normal shell
    – A.B
    Commented Aug 5, 2018 at 9:51
  • note: /etc/profile isn't used with su, only with su -. That was just an example.
    – A.B
    Commented Aug 5, 2018 at 10:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .