My sudo version is  $ sudo --version Sudo version 1.8.16 Sudoers policy plugin version 1.8.16 Sudoers file grammar version 45 Sudoers I/O plugin version 1.8.16  $ which sudo /usr/bin/sudo  $ whereis sudo sudo: /usr/bin/sudo /usr/lib/sudo /usr/share/man/man8/sudo.8.gz   :  # User privilege specification root    ALL=(ALL:ALL) ALL # my change for scaling down cpu freq t       ALL=(ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh   But after I reboot Ubuntu 16.04, I still need to provide password when running the script with sudo:  $ sudo /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh  1600000 [sudo] password for t:    I was wondering why?  Note that in /etc/sudoers,    I notice that the separator between root and ALL is a tab, and I also separate t and ALL with a tab, and the other separators are spaces. Originally I separated t and ALL with a few spaces, which didn't work. Does what the separator is matter? /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh is pathname without any symlink, and originally, I tried a symlink, which didn't work. Does a symlink matter or not?   Thanks.    Update:  As the reply by steve suggested, I changed the line in /etc/sudoers to be  t       ALL=(ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *   by adding * at the end, but it doesn't work.  Currently my /etc/sudoers looks like  # # This file MUST be edited with the 'visudo' command as root. # # Please consider adding local content in /etc/sudoers.d/ instead of # directly modifying this file. # # See the man page for details on how to write a sudoers file. # Defaults        env_reset Defaults        mail_badpass Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"  # Host alias specification  # User alias specification  # Cmnd alias specification  # User privilege specification root    ALL=(ALL:ALL) ALL # my change for scaling down cpu freq # t     ALL=(ALL:ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh * t ALL=(ALL:ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *  # Members of the admin group may gain root privileges %admin ALL=(ALL) ALL  # Allow members of group sudo to execute any command %sudo   ALL=(ALL:ALL) ALL  # See sudoers(5) for more information on "#include" directives:  #includedir /etc/sudoers.d   The groups of t include adm (is adm same as admin?) and sudo:   $ groups t t : t adm cdrom sudo dip plugdev lpadmin sambashare   The commands allowed to be run by t are:  $ sudo -l Matching Defaults entries for t on ocean:     env_reset, mail_badpass,     secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin  User t may run the following commands on ocean:     (ALL : ALL) NOPASSWD:         /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *     (ALL : ALL) ALL
121443
This is a sudoers file which I have on a Debian 9 server and it works.  /etc/sudoers contains:  Defaults    env_reset Defaults    mail_badpass Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"  # Host alias specification  # User alias specification  # Cmnd alias specification  # User privilege specification root        ALL=(ALL:ALL) ALL # the following line I've added for sudo to work on Debian, which by default does not vlastimil   ALL=(ALL:ALL) ALL # and this line I've added just now, so I could enable / disable teamviewer daemon as I wish vlastimil   ALL = (root) NOPASSWD: /usr/bin/teamviewer  # Allow members of group sudo to execute any command %sudo   ALL=(ALL:ALL) ALL  # See sudoers(5) for more information on "#include" directives:  #includedir /etc/sudoers.d   Meaning I can now run e.g. the following without entering password:  sudo teamviewer daemon disable sudo teamviewer daemon enable   This, however, is a non-working sudoers file on Linux Mint 18 in a sense, it still asks me for password. /etc/sudoers contains:  Defaults    env_reset Defaults    mail_badpass Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"  # Host alias specification  # User alias specification  # Cmnd alias specification  # User privilege specification root        ALL=(ALL:ALL) ALL # this line I've added myself, because I felt it is needed, however user vlastimil has had sudo access all the time, added just now vlastimil   ALL=(ALL:ALL) ALL # and this line I've added just now, so I could enable / disable teamviewer daemon as I wish, but it does not work vlastimil   ALL = (root) NOPASSWD: /usr/bin/teamviewer  # Members of the admin group may gain root privileges %admin ALL=(ALL) ALL  # Allow members of group sudo to execute any command %sudo   ALL=(ALL:ALL) ALL  # See sudoers(5) for more information on "#include" directives:  #includedir /etc/sudoers.d   I guess there is some difference between Debian and Mint, which makes the added lines non-working.  I read different answers like on this page:    But I am not clever from it.  EDIT1:  The first answer gives on Linux Mint a strange error:  $ sudo /usr/bin/teamviewer  Init...  *** TeamViewer can not be executed with sudo! ***  Either use your normal user account without sudo  or use a the real root account to log in to your desktop (not recommended!).   I don't get this either.    $ which teamviewer /usr/bin/teamviewer  $ file /usr/bin/teamviewer /usr/bin/teamviewer: symbolic link to /opt/teamviewer/tv_bin/script/teamviewer  $ file /opt/teamviewer/tv_bin/script/teamviewer  /opt/teamviewer/tv_bin/script/teamviewer: Bourne-Again shell script, ASCII text executable  $ cat /opt/teamviewer/tv_bin/script/teamviewer #!/bin/bash  # If you see this message, you probably attempted to start TeamViewer. # Please open a terminal (Konsole, gnome-terminal, xterm), # navigate to this folder (type 'cd /path/to/teamviewer' [Enter]) # then execute TeamViewer (type './teamviewer' [Enter])   TV_SCRIPT_DIR="$(dirname "$(readlink -e "$0")")" source "$TV_SCRIPT_DIR/tvw_main"  Main "$@"   EDIT2:  For instance on AskUbuntu, as suggested in comments:    and on many other places, there is a solution where they put the rule after admin group rule. I've tried it, even rebooted afterwards, but it's still not working.
31056
I've accidentally run this command  sudo mv /* /applications/minced/   instead of   sudo mv ./* /applications/minced/   This is all that's left in the root directory  $ / applications/ dev/          proc/         run/          sys/          tmp/          I still have an active ssh connection to the server. I've tried calling mv, sudo and chmod... directly from /applications/minced/bin/ or /applications/minced/usr/bin/, but nothing works, though I can locate them there using path autocompletion.   $ /applications/minced/bin/ls -bash: /applications/minced/bin/ls: No such file or directory   I've read , but mounting the system under LiveCD is not an option for me since it's a VPS, not a physical machine. Any ideas?  Update  I figured out this is due to library linkage problems, so I did this   $ export LD_LIBRARY_PATH=/applications/minced/lib/x86_64-linux-gnu/ $ /applications/minced/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /applications/minced/bin/mv /applications/minced/* /   Obviously I ran into permission problems. Calling sudo with the linker throws this error  $ /applications/minced/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /applications/minced/usr/bin/sudo ... sudo: effective uid is not 0, is /applications/minced/usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?   As suggested by Barafu Albino, I've tried calling su with busybox (.../bin/busybox su -), but it throws su: must be suid to work properly. I guess this happens because su can't locate /etc/passwd and /etc/shadow. Seems like I've screwed up the system completely.
64283
I have added alias ll='ls -la' in /etc/bash.bashrc but sudo ll is not working. Is there a way to "source" bash.bashrc? In a related post, another user suggesting creating an alias for sudo with a space after it. Eg. alias sudo='sudo ' but there wasn't any context to this answer. Should I add this to my bashrc? Seems hackish.  What is the correct method for adding an alias for my sudo one-off commands?
70834
Here's the script code I'm using now:  getent group $MYGROUP if [ $? -ne 0 ] ; then     sudo su -c "groupadd $MYGROUP" fi sudo su -c "useradd mynewuser -p mypassword -m -g $PRIMARYGRP -G $MYGROUP"   This approach works well on openSuse. But there are several problems with the user account it creates on Ubuntu so I am seeking help here.   the terminal prompt isn't set (echo $PS1 returns nothing) the arrow keys and tab key do not work correctly in the terminal the password doesn't seem to work (although I'm still unclear exactly what this issue is) the /etc/sudoers rights set for this new user are not honored   If instead I manually create the user with adduser (instead of useradd) I don't have these problems on Ubuntu. But I can't use adduser on openSuse (afaik). Therefore, I need a non-Debian-exclusive script or method of adding user accounts via my bash script that works on Ubuntu (and doesn't stop working on other distros).  Finally, I would like to understand  between adduser and useradd. For example, I want to know which skeleton directory is used by adduser as that might be the reason useradd isn't working as expected (because I just accepted the default).   Thanks
106477
Operating System: Arch Linux  Linux version: 4.16.11  Sudo version: 1.8.23  What I need:   be able to execute any executable with a sudo with a password prompt be able to execute one executable, /home/username/script.sh, without a password prompt.   When I configure like this  username ALL=(ALL) NOPASSWD: /home/username/script.sh   I have the desired effect on the script.sh, but I cannot execute any other executable with sudo.  Example  $ sudo ./script.sh # runs fine!   Attempt something other  $ sudo nano /etc/sudoers [sudo] password for username:  Sorry, user username is not allowed to execute '/usr/bin/nano  /etc/sudoers' as root on hostname.   Seems this is a result of replacing ALL with NOPASSWD, and seems I need both. If the sudoers file has ALL for the user, I can execute whatever I want with password prompt  username ALL=(ALL) ALL   I tried to combine ALL and NOPASSWD but had no results  username ALL=(ALL) ALL, NOPASSWD: /home/username/script.sh   Like this it asks for password for script.sh.  Can I have both?
98106
I am trying to find the correct reason for the stated question. My understanding is that:   sudo needs to read the /etc/sudoers file which is only readable by root, which is why it needs to be set-UID root su is going to create a new shell with a different real and effective UID, and needs to check the password. To check the password, it needs to read /etc/shadow, which is why it needs to be set-UID root. After checking password, it would need to call setuid() on the forked process, and to use an arbitrary UID argument, its parent process must have root as effective UID, so this also makes another reason.   Are the above reasons correct ?
1295
How does the ubuntu user on the AWS images for Ubuntu Server 12.04 have passwordless sudo for all commands when there is no configuration for it in /etc/sudoers?  I'm using Ubuntu server 12.04 on Amazon. I want to add a new user that has the same behavior as the default Ubuntu user. Specifically I want passwordless sudo for this new user.   So I've added a new user and went to edit /etc/sudoers (using visudo of course). From reading that file it seemed like the default ubuntu user was getting it's passwordless sudo from being a member of the admin group. So I added my new user to that. Which didn't work. Then I tried adding the NOPASSWD directive to sudoers. Which also didn't work.   Anyway, now I'm just curious. How does the ubuntu user get passwordless privileges if they aren't defined in /etc/sudoers. What is the mechanism that allows this?
45209
I have recently joined Ubuntu version 16.04. When i open the terminal it displays this message "To run a command as administrator(user "root"), use sudo command ". Please help me with this problem asap.  It happened to me (@waltinator), too. I did CtrlAltt to open a teminal, and is my wont, did 3 CtrlShiftt to open additional teminal screens. The additional screens got the message:  To run a command as administrator (user "root"), use "sudo &lt;command&gt;". See "man sudo_root" for details.   before my .bashrc finished.    I can't find anywhere in my .bashrc or its included files where I attempt to sudo anything (sounds like a Bad Idea) during my login process. I do set up aliases that sudo when evaluated, but not when defining the alias:  $ egrep 'sudo |su ' .bashrc .bash_aliases /etc/profile.d/color_ls.sh etc/bash_path_funcs/*  .bashrc:# makes "sudo" easier: sudo less $LESS files .bash_aliases:alias bigopenfiles="sudo lsof / | awk '{if(\$7 &gt; 1048576) print \$7/1048576 \"MB\" \" \" \$9 }' | sort -n -u"  .bash_aliases:alias deletedfiles="sudo lsof / | egrep 'PID|\(deleted\)'" .bash_aliases:alias bigopenfiles="sudo lsof / | awk '{if(\$7 &gt; 1048576) print \$7/1048576 \"MB\" \" \" \$9 }' | sort -n -u"  .bash_aliases:alias deletedfiles="sudo lsof / | egrep 'PID|\(deleted\)'" .bash_aliases:alias aptfixkey="sudo gpg --keyserver keyserver.ubuntu.com --recv-keys " .bash_aliases:alias susp="sudo -v &amp;&amp; sleep 20 &amp;&amp; echo 'Zzzzzzzzzzzzzzzzzzzzz' &amp;&amp; date &amp;&amp; sudo pm-suspend &amp;&amp; date &amp;&amp; echo 'Awake'" .bash_aliases:alias update='wupdatestatus=99;while [[ $wupdatestatus -ne 0 ]] ; do sudo apt-get update; wupdatestatus=$?;echo "status=$wupdatestatus";if [[ $wupdatestatus -ne 0 ]] ; then date; sleep 300; fi; done' .bash_aliases:alias upgrade='wupgradestatus=99;while [[ $wupgradestatus -ne 0 ]] ; do sudo apt-get upgrade; wupgradestatus=$?;echo "status=$wupgradestatus"; if [[ $wupgradestatus -ne 0 ]] ; then date; sleep 300; fi; done' .bash_aliases:alias upgradedl='wupgradestatus=99;while [[ $wupgradestatus -ne 0 ]] ; do sudo apt-get --download-only upgrade; wupgradestatus=$?;echo "status=$wupgradestatus"; if [[ $wupgradestatus -ne 0 ]] ; then date; sleep 300; fi; done' .bash_aliases:alias dist-upgrade='wupgradestatus=99;while [[ $wupgradestatus -ne 0 ]] ; do sudo apt-get dist-upgrade; wupgradestatus=$?;echo "status=$wupgradestatus"; if [[ $wupgradestatus -ne 0 ]] ; then date; sleep 300; fi; done' .bash_aliases:alias wup='wifi;sudo rmmod rt2800usb;sudo modprobe rt2800usb;nmcli con up id Nick;wifi;ping3 slashdot.org' .bash_aliases:    sudo tail -n 50 $( ls -rt1 /var/log |sed -e 's%^%/var/log/%'| tail -n 6 ) grep: /etc/profile.d/color_ls.sh: No such file or directory   None of the logs help:  $ sudo grep -l sudo /var/log/* /var/log/*/* 2&gt;/dev/null     shows nothing interesting.  How do I track down who/what is trying to sudo when I login?
49065
When I run sudo, what exactly happens to my environment?  When I run sudo command, it doesn't seem to see my or root's environment. For example, my path for both includes /usr/local/bin, but if I try to run one of the program's without the full path, it fails.  I thought sudo ran as root, and hence got root`s environment. Is there a different way that bash executes under sudo than under root or my normal user?  EDIT:  I have been using sudo -i lately, but recently it has been causing problems because my current working directory gets set to /root. This is as expected (sorta), but I still don't understand why sudo isn't recognizing my executables in /usr/local/bin.  EDIT:  I am running Fedora 15.
4367
This is a pretty simple question, at least it seems like it should be, about sudo permissions in Linux.  There are a lot of times when I just want to append something to /etc/hosts or a similar file but end up not being able to because both &gt; and &gt;&gt; are not allowed, even with root.  Is there someway to make this work without having to su or sudo su into root?
7276
I have always recommended pressing ALT+F2 and typing for example gksu nautilus or gksudo nautilus both are equivalent; to run graphical programs with root privileges.  However, I have just installed raring on a test system and this no longer works.  gksu and gksudo are not installed as part of a default raring install; though they are in the repositories. In 12.04 at least gksudo was just a symbolic link to gksu  The reasons I have always done this are because while it is often safe to use sudo under some circumstances it can cause problems with graphical applications because gksu has you running the program as root while with sudo you are running as yourself but with elevated privileges.  This can mean you inadvertently change the owner of critical system files.  This can cause problems.  This reasoning is explained better here:         Why was command removed from a fresh install and what should we be using instead?
120288
I'm a systems admin for a company and was thrown into a horribly configured server. In the midst of my refactoring I was adding users to my /etc/sudoers file. I seem to have accidentally removed my server admin account from the sudoers file access.  I know what I did wrong (i accidentally commented out the %admin line) question being, how can I reinstate my server admin access in the file without having to restart anything.   Here's how it looks right now:  ## ## User privilege specification ## root ALL=(ALL) ALL #%admin  ALL=(ALL) ALL %superuser ALL=(ALL) ALL "user1" ALL=(ALL) ALL "user2" ALL=(ALL) ALL   Also note that my users do not have permission for sudo for some reason:  Realtor-Station-3-27:~ user1$ sudo -i  WARNING: Improper use of the sudo command could lead to data loss or the deletion of important system files. Please double-check your typing when using sudo. Type "man sudo" for more information.  To proceed, enter your password, or type Ctrl-C to abort.  Password: user1 is not in the sudoers file.  This incident will be reported. Realtor-Station-3-27:~ user1$
777
This seems to be a chicken-egg problem. The most common task using sudo is installing and removing software.  sudo apt-get purge &lt;appname&gt;   But sudo itself can be removed.  sudo apt-get purge sudo # Do not run this command on production computers!   This is where the fun comes  ubuntu@ubuntu:~$ sudo bash: /usr/bin/sudo: No such file or directory   Although it's obvious that no person in his right mind will purge sudo (other than me), someone can be fooled to run this command (not directly, in its hex mode, or whatever it's called) or a person could SSH in disguised as tech guru and do the mess.  So is there a way of reinstalling sudo?
1809
In /etc/sudoers I see this:  # Allow members of group sudo to execute any command after they have # provided their password # (Note that later entries override this, so you might need to move # it further down) %sudo ALL=(ALL) ALL   So how do I add a user to that sudo group?
14250
What is the difference between the following commands:  su sudo -s sudo -i sudo bash   I know for su I need to know the root password, and for sudo I have to be in the sudoers file, but once executed what is difference?  I know there is a difference between su and sudo -s because my home directory is /root after I execute su, but my home directory is still /home/myname after sudo -s. But I suspect this is just a symptom of an underlying difference that I'm missing.
8729
In Ubuntu releases prior to Ubuntu 19.10 Eoan Ermine, when I run a command with sudo, that command receives my home directory in the $HOME environment variable. This is the behavior I have long expected and . If I want sudo to reset the $HOME environment variable, so that it refers to the target user's home directory instead of my own, I have to pass the -H option (or -i, though that does more).    ek@Kip:~$ lsb_release -d Description:    Ubuntu 18.04.3 LTS ek@Kip:~$ sudo printenv HOME  # Shows ek's home, not root's. /home/ek ek@Kip:~$ sudo -u as printenv HOME  # Shows ek's home, not as's. /home/ek ek@Kip:~$ sudo -H printenv HOME  # Shows root's home. /root ek@Kip:~$ sudo -Hu as printenv HOME  # Shows as's home. /home/as   When I first upgraded to Ubuntu 19.10, I was surprised to discover that sudo seems to reset $HOME no matter what! I continue to observe this now that 19.10 is released and I've installed updates--both on newly installed systems and one I upgraded to 19.10.  ek@Cord:~$ lsb_release -d Description:    Ubuntu 19.10 ek@Cord:~$ sudo printenv HOME  # Shows root's home, even without -H or -i. /root ek@Cord:~$ sudo -u as printenv HOME  # Shows as's home, even without -H or -i. /home/as ek@Cord:~$ sudo -H printenv HOME  # Also shows root's home. /root ek@Cord:~$ sudo -Hu as printenv HOME  # Also shows as's home. /home/as   I thought this might be due to .  But I checked, and always_set_home does not appear in any Defaults line in my 19.10 /etc/sudoers file.  What makes sudo treat $HOME differently starting in 19.10, and why was this change made? Does this make it safe to use plain sudo in cases where I would previously have used sudo -H?
776
When I'm about to install a program in the terminal it wants the password:  [sudo] password for xxx:   But when I start to type my password nothing happens. What should I do?