Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to use the su command to run an application as another user

In this case I am trying to run irssi

blah@ubuntu: su - [username] irssi
(enter password)

(nothing happens)

blah@ubuntu: su - [username] -c irssi

I run gksu and set same parameters and it works, and doesn't ask me for the user password. What is the issue? And how do I solve it?

I should note the user was created like this

adduser --system --disabled-login [username]

if it makes any difference....sigh.

share|improve this question
aren't you forgetting -c flag to launch irssi ? (su -c irssi) – eephyne Jan 15 '13 at 7:05
tried that too...tried a thousand things...why so hard to runas WTF thats exactly as the man page wants it...but nothing happens grrrr – user123361 Jan 15 '13 at 7:47
could it just be that irssi has an issue and that the su command works? – Nanne Jan 15 '13 at 7:55
Has the ´[username]´ proper rights to run irssi? – Doka Jan 15 '13 at 8:26
up vote 18 down vote accepted

This answer should still help you, even taking the edits to the question into account. In particular, an account created with --disabled-login has no password set and no other means of logging in, but it should still be possible to use sudo (explained below) to run commands or a shell as the user. This is, in fact, how the root account is set up in Ubuntu.

There are multiple problems with the command su - irssi.

This command tries to start a shell owned by a user named irssi.

It will fail if:

  • There is no irssi user.
  • The irssi user's account is disabled.
  • The irssi user's account is disabled for interactive login. Sometimes an account is permitted to use services like FTP but prohibited from logging in normally by setting their shell to something that quits immediately, like /bin/false. Then a login immediately ends, with no message.
  • The password you're entering is not correct for the irssi user.

The - flag makes it so the shell simulates an initial login shell--that is, so it's really very much like logging on as irssi. Without the - flag, if the su command succeeded, you'd still get a shell owned by irssi, but environment variables like HOME would be unchanged.

If you instead want to run a program called irssi, you must invoke su differently:

su username - -c irssi

If you leave out -c username, it's the same as -c root--it attempts to run the command as root.

Alternatively you can start a shell and then run the command:

  1. Start the shell with su username -.
  2. In the shell, run the command (irssi).
  3. If you're done, leave the shell by running exit.

Running Commands as root

If you want to run irssi as root, su is not the way to do it. Root logins are disabled by default on Ubuntu, and there is only rarely any reason to re-enable them. If you have enabled root login, then you should be able to use su to become root. The reason it's unnecessary to enable the root account is that, whether or not you do, you can still run commands as root with sudo.

When you run commands with sudo, you put in your password, not the password of the user under whose identity you wish the command to run. Only administrators may run arbitrary commands as root with sudo (unless you reconfigure sudo to allow others to do so, of course). So a user who is not allowed to administer the system is not allowed to run commands as root with their own password.

To run irssi as root with sudo:

sudo irssi

And you would enter your password when prompted, not root's.

Except what password you enter, this does the same thing as:

su -c irssi

Except the sudo version can succeed because it doesn't require the root account to be enabled.

Like with su, you can use sudo to run commands as another, non-root user. To run irssi as username with sudo:

sudo -u username irssi

If you want sudo to behave like su - with respect to HOME--that is, you want to use the target user's HOME environment variables, you can run sudo with the -H flag:

sudo -H irssi
sudo -H -u username irssi

You can start a whole shell with sudo, like you can with su. Except for whose password you put in, this command has the same effect as su:

sudo -s

And this command has the same effect as su -:

sudo -i

(The i stands for initial login shell.)

You can start a shell as another user, too:

sudo -u username -s
sudo -u username -i

Further Reading on sudo

To learn more about sudo, take a look at:

Why did gksu work when su didn't?

gksu probably worked by running sudo.

gksu is a frontend for both su and sudo. In Ubuntu, it defaults to using sudo (since in Ubuntu, su is typically not used for becoming root, and is only a secondary way of becoming other, non-root users).

You can make gksu use su as the frontend by running gksu --su-mode.

You can find out whether gksu is in su mode or sudo mode, and (if you wish) change this setting, by running gksu-properties. This is a per-user setting.

When gksu is in sudo mode, it behaves the same as gksudo.

Further Reading on gksu

Post-Solution Analysis

You found ultimately that you were able to run the necessary command with:

sudo -u username irssi

(Which is of the techniques listed above.)

Ultimately, you reported two pieces of information, which are sufficient to explain why it was that other techniques had failed, but that had succeeded:

  1. The username account was created with the --disabled-login flag, which makes it have no password (and no other means of logging in). Having no password doesn't mean it's possible to log in with a blank password. It means no password is sufficient to authenticate. In combination with the elimination of other means of authentication, this means username cannot authenticate at all.

    So all su-based solutions are out. sudo can work though, because with sudo you don't authenticate as the user you're about to impersonate. Instead, you have to be authorized to impersonate them, and you authenticate as yourself (i.e., enter your own password, not theirs).

    It's possible to set a password on the account, which removes this barrier to logging in:

    sudo passwd username

    However there might be a good reason the user is not allowed to log in. For example, if this user were allowed to log in, and logged in graphically, would bad problems arise from the user's environment or privileges being poorly suited to running X11 apps? If this user could log on, would that make it possible to log on remotely as that user (for machines where you have exposed network services)?

    If you ever want to re-disable it:

    sudo passwd -dl username

    Related: Re-disabling the root account after having temporarily enabled it.

  2. The username account has /bin/false as its login shell.

    When a shell like bash runs as your login shell, it sets up your environment and gives you an interactive prompt with which to control the machine.

    When /bin/false runs, on the other hand, it does nothing, and reports failure. (/bin/true does nothing and reports success.)

    The false and true commands are useful in scripting and for various testing purposes, but also for disabling an account so that when someone logs in, their login session immediately ends. That way, a password (or other means of authentication) can be enabled, and people can log in, just not for shell access. For example, if there is an FTP server, they could still access their account via FTP. If there is an SSH server, they wouldn't be able to get a shell via SSH, but they could still use sftp and scp to transfer files.

    Since username's login shell was nonfunctional, commands like su username, su - username, sudo -u username -s, and sudo -u username -i could not work.

    But commands that don't give a shell, like sudo -u username command or su username -c 'command' could still work.

    Since commands can be run, you can change the user's login shell to something functional:

    sudo chsh -s /bin/bash username

    However, this should also be done with caution, as there may be a good reason to disable interactive logins for the user.

Here, username both had disabled password and "disabled" shell. The absence of any working password prevented all su-based solutions from working, while the absence of a working interactive login shell prevented all shell-spawning solutions from working (except manually invoking a shell, like sudo -u username bash).

sudo -u username command is what remained.

share|improve this answer
Sorry for the many edits while you were working on your answer. Wow. Thank you. When I do cat /etc/passwd the user I have configured has /bin/false at the end - so is this what is causing it to fail? any idea how to fix that ? – user123361 Jan 15 '13 at 8:20
For whatever reason, using sudo -u username irssi works the treat. Thanks for your lengthy, well explained answer! – user123361 Jan 15 '13 at 8:23
@db I'm glad it worked! (Btw, no need to apologize for editing, editing is very, very good, and your question will likely be useful for more other people too as a consequence of the edits.) As for your other questions, I've edit my answer to include an analysis section at the end. – Eliah Kagan Jan 15 '13 at 9:09

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.