Let's say I've gone and done a silly thing, such as using 'chsh' to change the root user's shell to a bad file path. Future logins to the root account will abruptly fail, citing /bin/whatever not being found, and boot you back out to the login screen. Barring a recovery mode or inserting a LiveCD to edit /etc/passwd, what are my options for getting my system back? Let's also assume (for fun?) that there are no other users in wheel. Thoughts?

  • Is this a hypothetical situation that you are proposing?
    – Chris Down
    Commented Sep 18, 2011 at 21:53
  • I had indeed done exactly this on a (relatively fresh) FreeBSD install. It has since been reinstalled, so I suppose it is now somewhat hypothetical, but I'm curious about what the best route to recovery would have been if I indeed did have full system present.
    – noffle
    Commented Sep 18, 2011 at 21:59
  • Been there, done that, got the t-shirt. But as a result on every machine I administer I maintain a backup root account, just in case.
    – Mark D
    Commented Sep 20, 2011 at 20:37

5 Answers 5


When booting, append init=/bin/bash (or a path to any other functional shell) to your boot options - you will be dropped straight to a single user shell. You might need to do mount -o remount,rw / before modifying the /etc/passwd entry in that environment. After that, just reboot or do exec /sbin/init 3. Just do not type exit or press Ctrl+D, as these would result in kernel panic*.

One additional variation of this method might be necessary on some systems loaded in two-stage mode (with an initrd image). If you notice that the boot options contain init= and, most importantly, real_init=, then the place to put /bin/bash should be the latter parameter (i.e. real_init=/bin/bash).

* This is because in that environment, the shell is seen by the kernel as the init program - which is the only process that kernel knows - it represents a running system underneath to the kernel's eye. Suddenly ending that process, without telling the kernel to shutdown the system, must result in kernel panic. (Wouldn't you panic if suddenly everything around you went black and silent?)

  • Nice for the exec, but I guess it's better not to mess up too much with mount points beforehand. Commented Sep 18, 2011 at 23:12
  • 2
    @Stéph You have to do that if your kernel does not mount root read-write. Otherwise you won't be able to modify any files (including /etc/passwd). Commented Sep 18, 2011 at 23:18
  • Good thinking! I had managed to get into single-user mode, but it didn't hit me that I had to remount / as read/write to modify /etc/passwd. Thanks!
    – noffle
    Commented Sep 19, 2011 at 2:16
  • @roz Sure, I was trying to say that I would take care of unmounting everything else might have been mounted (other than /) before executing init. Commented Sep 19, 2011 at 10:41
  • @Stéph There should be no problems with mounts. Notice that /bin/bash is run exactly at the point, then /sbin/init would be executed on normal boot. So there can be no possible action done by the system at that time. Commented Sep 19, 2011 at 11:55

You could use su and specify a shell to execute (I'm not sure if you're trying to imply this isn't possible with your note about no other users being in wheel):

su -c /bin/bash

Otherwise you could do something similar if your ssh daemon allows login to root:

ssh root@localhost /bin/bash

You could also set a shell as your init in your bootloader, for example, init=/bin/ksh or similar.

  • 1
    Good ideas. =) As you suspected, no other users can use 'su'. sshd also has root login disabled.
    – noffle
    Commented Sep 18, 2011 at 21:48

If your bootloader is configured to allow live editing of the kernel parameters, a solution is to reboot and use a shell as init process, e.g. init=/bin/bash. Then, mount whatever needs to be mounted by hand, and edit /etc/passwd. sync and boot again with your usual init.

  • Wow, I just noticed you posted the same answer in the same minute as myself :-) Commented Sep 28, 2011 at 8:30

If the gist of your question is that you've locked out all the ways to become root, then by definition you cannot become root.

It is common to allow three ways to become root on a unix system:

  • Log in as root, by entering root at a login prompt and typing the root password. This runs root's shell.
  • Log in as an ordinary user, then become root by running su and typing the root password. On some systems, this requires being in a particular group (often called wheel); on other systems, anyone who knows the root password can become root. Systems using PAM for authentication use pam_wheel to manage the wheel group if they have one. If you specify a command with su -c, it is executed via root's shell.
  • Log in as an ordinary user, then become root by running sudo and typing your own password. The user account must have been given sudo powers by an administrator. Unless restricted in the sudoers file, you can run any command, regardless of root's shell.

A traditional way to protect against root's shell being unavailable is to define another account with UID 0 and a different shell (toor is a traditional name). For example, if root's shell is a dynamically linked executable (a good idea to conserve memory) and a library upgrade goes wrong, root's shell might be unusable. The alternate root account would have a statically linked executable, possibly one with common utilities built-in such as BusyBox.


The above answers are great and I learned from reading them. If you don't remember the details of these approaches and don't mind rebooting, you can always boot your system using a live CD distro, mount the / partition and then edit /etc/passwd and reboot. Not as elegant as the above solutions, but easier to remember.

  • 1
    You should point out the risks connected with manually editing the /etc/passwd file. Other than this, good point - I just wanted to add the same suggestion to my answer. Commented Sep 28, 2011 at 8:35

You must log in to answer this question.

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