$ 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” 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
    Aug 6, 2018 at 9:15
  • Also please state if using stretch/stable, buster/testing or sid/unstable overall
    – A.B
    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
    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
    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. 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
    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 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
    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 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
    Aug 5, 2018 at 9:51
  • note: /etc/profile isn't used with su, only with su -. That was just an example.
    – A.B
    Aug 5, 2018 at 10:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.