0

I am running Debian 10 (upgraded from 9) and I recently noticed that quite a few commands appear to be missing from the system unless they are run with sudo - bash says that they are not found.

$ reboot
bash: reboot: command not found

This happens even if they are ran as root. Quite a few utilities act this way, including:

  • shutdown and reboot

  • many partitioning tools such as fdisk and gparted

  • update-grub and grub-install

  • modprobe

I like to run commands without sudo in case I make a mistake, then sudo !! when I am sure it is typed correctly, but this misleading message has led to me going on a wild goose chase looking for a command which was in fact on my system the whole time.

Notably, the manpages are still there and can be viewed as a normal user.

Why don't I get an only root can do that error like with mount? Is this behavior more secure? Also, is there any way I can turn it off?

  • $ echo $PATH and $ sudo echo $PATH (that's 2 commands). Is there a difference? – Rusi Jan 10 '20 at 15:08
  • 2
    @Rusi that's unlikely to be helpful for a couple of reasons (1) sudo is usually configured to use its own secure_path and (2) in sudo echo $PATH, the $PATH variable will be expanded by the invoking shell – steeldriver Jan 10 '20 at 15:10
  • 1
    Relating https://unix.stackexchange.com/q/232782/117549 – Jeff Schaller Jan 10 '20 at 15:14
  • … and of course https://unix.stackexchange.com/q/467552/5132 , https://unix.stackexchange.com/q/432889/5132 , https://unix.stackexchange.com/q/318179/5132 , https://unix.stackexchange.com/q/402331/5132 , https://unix.stackexchange.com/q/83191/5132 , https://unix.stackexchange.com/q/341455/5132 , https://unix.stackexchange.com/q/91541/5132 , https://unix.stackexchange.com/q/245772/5132 , https://unix.stackexchange.com/q/552066/5132 … – JdeBP Jan 10 '20 at 15:38

3 Answers3

2

Thanks to the comments I learned that /sbin and /usr/sbin are excluded from $PATH by default on Debian. I remedied this by adding the following line to my ~/.bashrc:

PATH=$PATH:/sbin:/usr/sbin

All commands now appear as normal:

$ update-grub
grub-mkconfig: You must run this as root
0

Have you checked your PATH environment variable? This often happens when someone modified PATH variable by accident and can the executeable search path broken..

kokei
  • 69
  • 1
    In particular, the user's PATH is likely missing /sbin and possibly /usr/sbin – steeldriver Jan 10 '20 at 15:11
  • 2
    /sbin/ and /usr/sbin/ paths are often excluded from the PATH variable by design, because the executables in those directories typically require root privileges, and are thus not expected to be run by normal users. – Mr. Donutz Jan 10 '20 at 15:15
0

(As commented under another answer:) "/sbin/ and /usr/sbin/ paths are often excluded from the PATH variable by design, because the executables in those directories typically require root privileges, and are thus not expected to be run by normal users."

Use the full sudo command, but start with echo instead. Then, if something goes wrong, like accidentally you hit the Enter key, the command is simply displayed on screen and you return to the command prompt without anything actually happening (be careful with command substitutions, though). Then, you can use the Up arrow to go back to edit the command as you were.

Check the manual pages of the commands themselves as well, because some of them offer an option to only show what the command would do, without actually doing it.

For example, sfdisk has the option -n (or: --no-action), which does all the things you ask it to do, but does not write to the device, so no actual modifications are made.

To make permanent changes, edit the .bashrc file in a user's home directory (if you use BASH). To make the change permanent for new users, you can set up or change a relevant file in /etc/skel/. The contents of this directory are, under default behaviour, copied in the home directories of any new users you add.

Security Notice: The tutorial in the following link suggests adding a bin/ directory in the home directories for each user to allow them to use their own executables. However, a good security practice is to disable executables from being run from a /home partition, by using the noexec modifier in fstab. Doing this will ensure that only admin-approved executables can be run. The /usr/local/ directory tree provides space to add executables that do not come through a standard (safe) repository, so that admin control can be maintained while still allowing expansion from the standard packages provided by the distribution.

Perhaps useful to look at a short tutorial like this one: https://www.tecmint.com/set-path-variable-linux-permanently/