Is not in the sudoers file. This incident will be reported


Suddenly i get this strange failure where i’m told that my user ain’t part of sudo anymore which means that i’m not able to do a sudo su to gain root access though the web console or SSH (i have no problems with logging in and everything is running, i just can’t get root access). So i can’t run any sudo commands since my user no longer is part of the sudoer and i can’t fix this because i can’t gain root access

At the same time i can’t remove any of the packages since i can’t get into root access and my rtorrent keeps telling me “Plugin will not work. rTorrent user must have read/execute access to the file”

I hope that someone have a solution for this that doesn’t involve delete my seedbox with more than 4TB data on it.

do you know the root password?

if so then just type su -
and enter the root password when prompted.


Yes, i do know the root password, but the root password isn’t being accepted when i enter it

Can’t boot into recovery mode on my dedicated server, so unfortunately that’s not an option :frowning:

I just ran into this issue as well after a new install. Something managed to wipe out my sudoers file contents completely (0byte file) and I was unable to gain root access since there is no password by default for it in Ubuntu. Luckily this is on a VM so, I was able to boot my VM with a live CD, mount the root filesystem, copy over/reinstall the default sudoers file, and add users back to the admin/sudo groups as needed. I’m not sure if that is an option available to you from the server provider or not.

I’m not specifically sure what caused it, but it might have something to do with the template file used during the install. It is definitely related to installing QuickBox, however.

The only reason that a sudoers file would empty is if the template is not in the right spot to replace it or perhaps an interrupted upgrade.

I’ve been meaning to move to a more appropriate sudoers.d template which would prevent sudo access from being removed in case of error; however these cases are few and far between and often a result of misconfiguration or improper repository location.

@wizard are you using su - to try to access root?

Yes, i’m using su - when i’m trying to access root (the problem happened a couple of days ago after i had ran an update on the quickbox script though the desktop, after that i’m not able to access root and at this point my only option is to reinstall my dedicated server and loose everything on it since it won’t accept my root password and i can’t change my root password remotely)

I would suggest next time that you setup passwordless ssh on your server. I dont know my root password off the top of my head(its like a random 25-30 digit password) but I ssh into my server using my normal account and root.

There is no way you can even log into the server with a password. It’s totally disabled.

We don’t alter root passwords, if you can’t access from su - then your password is wrong (are you sure you’re not using your user password?).

While the sudo issue is rare and far between, @RXWatcher makes a great point: password-less root login for your server is an extremely handy method to ensure this never happens on your server. If you don’t know the root password and sudo gets reset, it might be your only hope at recovering sudo if you don’t have access to recovery.

After spending countless hours on trying to get my root access back so i could add my user to sudoers again, i finally got it up and running again (i always have my servers setup with an extra admin user no matter if it’s a linux server or a windows server, the problem was just, that after the last update then it had wiped out my sudoers file and replaced it with a standard one).

Now the problem is just, that my Sonarr won’t play nicely together with Jackett (sonarr says it’s unable to connect to the indexer, but when i test it in jackett it connects fine), my rtorrent says that the rtorrent user don’t have read/write access to the directory /srv/rutorrent/plugins/unpack/ and i can’t add/remove packages in the desktop.

Same thing happened with me today. Why is there a need to update the sudoers file to remove other users sudo access? It can add the master user to sudoers file but no need to remove any other user.

This done -

  • Run updateQuickBox command
  • sudoers file got modified and user with sudo access was removed from it

We perform updates to the sudoers file from time to time which means we need to update it with every update (as we have no way of knowing which version people are upgrading from).

We do this by deleting the file /etc/sudoers, copying the template in it’s place and reinserting the master user into sudoers. I am planning on making the switch to moving our template to /etc/sudoers.d eventually; however I have had little time to devote to the project recently. Once the switch has been made, /etc/sudoers can be modified and the contents of this file will not be touched. It should also allow the user to retain root access in event of a botched template copy as sudo users will be written directly to /etc/sudoers and quickbox specific commands will be pushed to the other file.

As a personal work around, you are welcome to use a file in /etc/sudoers.d should you feel the need to add extra sudo users that are not the master user, for now.


I’m not added to sudoers so if I have to do something involving root I need to login directly as root.
looking at the thread here I’m a bit uncomfortable messing with the sudo file directly.

In the folder /etc/sudoers.d I only have a readme encouraging me to use visudo to edit the sudoers directly.

I’m using Debian-85-jessie-64-minimal as base for my quickbox.

Any advice on how to add my user to sudoers in a safe way?


If you guys are ever in doubt over this the current eco-system is stored in /root/QuickBox. The sudoers template is also addressed here:

Remember to add above root ALL=(ALL:ALL) ALL your sudo users name,
i.e; jmsolo ALL=(ALL:ALL) ALL at line #27