To run the command poweroff or reboot one needs to be super user. Is there anyway I can run this as a normal user? I just don't want to sudo and enter my password every time I reboot or power off.

  • 2
    The answer depends on which init system your distro uses... For example, with systemd and an active logind session you can reboot or poweroff without elevated privileges providing no other user is still logged in...
    – jasonwryan
    Aug 6, 2013 at 8:29
  • @jasonwryan I am currently using Ubuntu which doesnot use systemd by default.So you mean other Distros such as Arch can reboot without elavated privileges?
    – Stormvirux
    Aug 6, 2013 at 9:17
  • Yes: as per the conditions in my first comment.
    – jasonwryan
    Aug 6, 2013 at 9:36

7 Answers 7


I changed /etc/sudoers so that every user that is in the admin group can execute the following commands without being ask for a password.

sudo halt
sudo reboot
sudo poweroff

You just need to add the following lines to /etc/sudoers

## Admin user group is allowed to execute halt and reboot 
%admin ALL=NOPASSWD: /sbin/halt, /sbin/reboot, /sbin/poweroff

and add yourself to the admin group.

If you want only one user to be able to do this just remove the %admin and replace it with username like this

## user is allowed to execute halt and reboot 
stormvirux ALL=NOPASSWD: /sbin/halt, /sbin/reboot, /sbin/poweroff

You can find out more about /etc/sudoers with man sudoers or the online manpage


You can also create a new file under /etc/sudoers.d name it as you wish(I named it 'shutdown'), and put the following lines inside:

# Allows me to shutdown the system without a password

yourUserName ALL = NOPASSWD: /sbin/halt, /sbin/reboot, /sbin/poweroff

Just change "yourUserName" for YOUR User Name, and add or remove commands to use, personally I use it only for shutdown. One of the main difference of creating a particular file under sudoers.d is that this file will survive System Upgrades

  • 2
    If you choose this approach, ensure that /etc/sudoers has an appropriate #include directive to read files from /etc/sudoers.d/. Sep 30, 2019 at 23:13
  • Even with the #includedir directive, this doesn't work. When testing this as non-root user with reboot, I receive the following: Failed to set wall message, ignoring: Interactive authentication required. Failed to reboot system via logind: Interactive authentication required. Failed to open initctl fifo: Permission denied Failed to talk to init daemon.
    – jimjamz
    Jun 1, 2023 at 21:34
  • @jimjamz I had that error as well, but then I realized I had to type sudo reboot not just reboot. No password prompt, but prompt reboot.
    – Joe Skeen
    Jan 22 at 5:06
  • @JoeSkeen I think using sudo defeats the whole purpose of this topic and what we're trying to do here.
    – jimjamz
    Jan 23 at 15:47
  • True, but for me it was more about not requiring the interactive password prompt, which this fixed, even if you have to use the sudo command.
    – Joe Skeen
    Feb 15 at 23:21

Simplest solution:

sudo echo $USER >> /etc/shutdown.allow

Then you're able to use one of this commands:

shutdown -ah now   // halt
shutdown -ar now   // reboot

According man shutdown there is -a option for non-root usage:

If shutdown is called with the -a argument (add this to the invocation of shutdown in /etc/inittab), it checks to see if the file /etc/shutdown.allow is present. It then compares the login names in that file with the list of people that are logged in on a virtual console ...

It works in Debian Linux. And there is limit for 32 user names in /etc/shutdown.allow.

  • 4
    No such option on Fedora, CentOS or RHEL.
    – fpmurphy
    Nov 1, 2017 at 5:02
  • 1
    This is also not working for Ubuntu, at least that is what I get from the docs. It would be helpful to see if this is a Debian only feature. Nov 1, 2017 at 7:28
  • 1
    Still not in Ubuntu (18.04) in 2020 =}
    – tink
    Jan 15, 2020 at 21:57
  • My fresh Debian 12's man entry doesn't talk about shutdown.allow or -a anywhere. Is there a package I need before it will work like yours?
    – Ninjaxor
    Oct 3, 2023 at 19:30
  • This is part of sysvinit-core documentation. Check for more details on man pages online. Oct 4, 2023 at 10:17

You can also achieve this by trick with setuid. I don't know if it will work on all systems, because they sometimes ignore setuid/setgid bit.

You can specify a group of users who can perform change of system state in my case it was adm. Then add appropriate users to this group.

gpasswd -a $USER adm

Specify permissions:

chmod 4550 /usr/bin/reboot

ls -l outpus should look like this:

-r-sr-x--- 1 root adm 18928 Mar 13  2015 /usr/bin/reboot

Afterwards you can just type:

  • 7
    Don't do this with systemd! With systemd, the reboot command is a symlink to systemctl, so you'll actually change systemctl to be setgid, and systemd does some security stuff (like don't trust env variables in setuid/gid programs) that will break it when setuid/gid.
    – TrentP
    Mar 12, 2020 at 22:02
  • I would generally not do this. Setuid is a security risk (see the comment about systemd). Which you can easily avoid using sudo as explained in some of the other answers.
    – Thawn
    Oct 5, 2021 at 20:01
  • Thanks for pointing that out, but I don't see a security risk here. If reboot is a symbolic link then of course don't do it, but if you don't use systemd as an init system and your reboot program is small and does only one thing then everything is Ok. You should just always use some common sense before using whatever solution you've found on the internet. Regarding an answer involving modification of sudoers file - it still requires to enter sudo reboot which doesn't address OP's wish to not write sudo at all.
    – hurufu
    Oct 8, 2021 at 7:50

Another way to achieve not only boot privileges but access to all systemctl services for a specific user or group in a Debian system is doing this:

sudo chown root:myuserorgroup /bin/systemctl
sudo chmod 4755 /bin/systemctl

Because all boot scripts /sbin/shutdown, /sbin/poweroff, /sbin/reboot are links to /bin/systemctl, changind its permissions and ownership grants the necessary privilege to execute it as root user.

Be aware that the user will be able to execute all systemctl operations. This may sound as a security threat, but it is a simple general solution to embbeded systems where your default user must not only have the access rights to shudown but also to work with all the other system services related to systemctl.


Here's what I have done when I needed this. It may not work if the shutdown needs to happen right away, but it has the advantage that it needs neither extra privilege nor sudo.

  • Create and maintain a directory somewhere (maybe under /var/tmp) which is normally empty but fully accessible by you
  • When you need to force a shutdown, just touch an empty file into existence in that directory
  • A root cron job runs every minute and checks if that file exists
  • If so, the cron job removes the file and shuts down.

I did this in the context of shutting down a Raspberry Pi when the UPS hat [1] on it stays on battery power for too long. I wanted to run the monitoring script as a normal user.

  1. https://www.pishop.us/raspberry-pi-ups-hat-guide/

Warning: do not look at the code on that webpage, it is very bad for your eyes :-P


In some cases (like some small embedded Linuxes, for example from standard yocto images) there is a group in /etc/group called shutdown which owns the executable for reboot. So in that case you just have to add this user to that group.

You must log in to answer this question.

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