Linux Commands Examples

A great documentation place for Linux commands


change user ID or become superuser

see also : login - sg - sh


su [options] [username]

add an example, a script, a trick and tips

: email address (won't be displayed)
: name

Step 2

Thanks for this example ! - It will be moderated and published shortly.

Feel free to post other examples
Oops ! There is a tiny cockup. A damn 404 cockup. Please contact the loosy team who maintains and develops this wonderful site by clicking in the mighty feedback button on the side of the page. Say what happened. Thanks!


sudo su -
su -
su -

Sudo su vs su linux

That's because su asks for password of the user you're changing into (which by default is root) while sudo asks for your own user account's password and checks if you are allowed to run the command.

When you run sudo su you are asking sudo to run the command su as root, which gives you the root shell. If you are using only su you will have to know the target user's password to have access.

Using sudo without parameters implies that you want to use root. If you want to execute the command as another user, try sudo -u <username> <command>


Is it possible for root to execute a command as non-root

Short answer: "Yes, this is possible".

if you like to execute a non-X application then just use the following command:

sudo -u abc command

If you like to run some X application as another user but with your own desktop first you need to create a helper script, that will make your life simpler

  • create a bin folder under your home directory:

mkdir -p ~/bin

and using your favorite text editor create a file ~/bin/xsudo as follows:

# (C) serge 2012
# The script is licensed to all users of StackExchange family free of charge
# Fixes/Enhancements to the script are greatly appreciated. 
# SUDO_ASKPASS has to be set to the path of ssh-askpass
# fix the following two lines if your distribution does not match this autodetection
. /etc/profile.d/

xauth nlist "${DISPLAY}"|sudo -HA -u $SUDOUSERNAME env --unset=XAUTHORITY \
bash -c "xauth nmerge - ; $*"

then make it executable:

chmod +x ~/bin/xsudo

and use it the same way as sudo but without any switches:

xsudo user application


P.S. Starting xsession from the root account is strongly discouraged!


What's the difference between "su" with and without hyphen?

The difference between "-" and "no hyphen" is that the latter keeps your existing environment (variables, etc); the former creates a new environment (with the settings of the actual user, not your own).

The hyphen has two effects:

1) switches from the current directory to the home directory of the new user (e.g., to /root in the case of the root user) by logging in as that user

2) changes the environmental variables to those of the new user as dictated by their ~/.bashrc. That is, if the first argument to su is a hyphen, the current directory and environment will be changed to what would be expected if the new user had actually logged on to a new session (rather than just taking over an existing session).


Can't write to file /sys/class/backlight/acpi_video0/brightness (ubuntu)

The error happens because sudo elevates permissions for the command (sudo echo 5) but not the redirection to write the file (> /sys/class/backlight/acpi_video0/brightness). The actual bash shell needs permission to write, which is why it fails with sudo but works as root.

You can work around this by running the tee command as root to write to the file:

echo 5 | sudo tee /sys/class/backlight/acpi_video0/brightness

Note that this will also echo "5" to your terminal. This is a normal side effect of the tee command.


Any differences between `su` vs. `su -` beside the pathing?

AFAIK su - simulates a fresh login, so triggers everything related to logging in, while su simply switches the user to root.


a safer no password sudo?

Try adding this to your sudo options:

Defaults timestamp_timeout=0, tty_tickets

tty_tickets option (on by default) will make sudo ask password if it was not asked previously in that particular tty (including terminal emulators ptys), and timestamp_timeout=0 option will make it not ask it again in the whole session.

So, when you want to do some administrative operations, you can open terminal, sudo something, close it, and you will be safe again.


Using su with commands

The problem is that suser was created with /bin/false as its default shell. Therefore, when you try to run commands as suser through sudo, the system attempts to run them using /bin/false/ which is not a real shell and fails. You can either set a shell for suser or you can specify it on the command line when you run sudo. Alternatively, you can use sudo's -u option.

  1. Use -u:

    sudo -u suser mkdir /home/suser/foo

    This works because by default, sudo uses /bin/bash (or whatever you have set the default $SHELL to be). Therefore, it will execute a command as suser but using bash, so the command is correctly executed.

  2. Set suser's default shell:

    sudo chsh suser 

    Enter /bin/bash (or whatever you prefer) in the prompt that will appear. You should now be able to launch commands as suser:

    sudo su suser -c "mkdir /home/suser/test"
  3. Set the shell explicitly:

    sudo su suser -s /bin/bash -c "mkdir /home/suser/test"

What's the difference between sudo su - and sudo -i?

There is little difference in the command pairs you are wondering about.

The first pair attempts to simulate a fresh login as the new user-- there could be some difference in the environmental variables supplied, as sudo su - is going to try and preserve existing environmental variables, while sudo -i will set very specific environmental variables and strip all others (check your man pages for specifics).

For the second pair, the difference in behavior is this: sudo su will always start the shell listed in the user's /etc/passwd, whereas sudo -s will check the SHELL environmental variable first, and only execute the shell in /etc/passwd if SHELL is unset.


Use su to switch to a local (mutually-trusted) user, without a password?

How is setting up an ssh public key "inelegant"? I'd say that's the right way to do it, and it doesn't require root access; just append user2's public key to ~user1/.ssh/authorized_keys. If user2 is logged into the system, he can just type ssh user1@localhost with no significant network overhead.

You could also configure /etc/sudoers so that user2 can run sudo su user1 and/or sudo su - user1 without entering a password. (This doesn't get the extra points, since it requires root access to configure /etc/sudoers.)


Any latest linux distro which gives full root access ( NO SUDO )?

Becoming root for one session:

In Ubuntu you can become root for the remainder of the session by typing:

# old-school method
sudo su

# new hotness, comes highly recommended
sudo -i

More information and related reading.

Permanently enabling the root account:

Further, you may permanently enable the root account by typing:

sudo passwd root

and providing a root password. You can then log in as root at your leisure without needing to use sudo.


The su command is used to become another user during a login session. Invoked without a username, su defaults to becoming the superuser. The optional argument - may be used to provide an environment similar to what the user would expect had the user logged in directly.

Additional arguments may be provided after the username, in which case they are supplied to the user's login shell. In particular, an argument of -c will cause the next argument to be treated as a command by most command interpreters. The command will be executed by the shell specified in /etc/passwd for the target user.

You can use the -- argument to separate su options from the arguments supplied to the shell.

The user will be prompted for a password, if appropriate. Invalid passwords will produce an error message. All attempts, both valid and invalid, are logged to detect abuse of the system.

The current environment is passed to the new shell. The value of $PATH is reset to /bin:/usr/bin for normal users, or /sbin:/bin:/usr/sbin:/usr/bin for the superuser. This may be changed with the ENV_PATH and ENV_SUPATH definitions in /etc/login.defs.

A subsystem login is indicated by the presence of a "*" as the first character of the login shell. The given home directory will be used as the root of a new file system which the user is actually logged into.


The options which apply to the su command are:

-c, --command COMMAND

Specify a command that will be invoked by the shell using its -c.

The executed command will have no controlling terminal. This option cannot be used to execute interractive programs which need a controlling TTY.

-, -l, --login

Provide an environment similar to what the user would expect had the user logged in directly.

When - is used, it must be specified as the last su option. The other forms (-l and --login) do not have this restriction.

-s, --shell SHELL

The shell that will be invoked.

The invoked shell is chosen from (highest priority first):

The shell specified with --shell.

If --preserve-environment is used, the shell specified by the $SHELL environment variable.

The shell indicated in the /etc/passwd entry for the target user.

/bin/sh if a shell could not be found by any above method.

If the target user has a restricted shell (i.e. the shell field of this user's entry in /etc/passwd is not listed in /etc/shells), then the --shell option or the $SHELL environment variable won't be taken into account, unless su is called by root.

-m, -p, --preserve-environment

Preserve the current environment, except for:


reset according to the /etc/login.defs options ENV_PATH or ENV_SUPATH (see below);


reset to “<space><tab><newline>”, if it was set.

If the target user has a restricted shell, this option has no effect (unless su is called by root).

Note that the default behavior for the environment is the following:

The $HOME, $SHELL, $USER, $LOGNAME, $PATH, and $IFS environment variables are reset.

If --login is not used, the environment is copied, except for the variables above.

If --login is used, the $TERM, $COLORTERM, $DISPLAY, and $XAUTHORITY environment variables are copied if they were set.

Other environments might be set by PAM modules.


This version of su has many compilation options, only some of which may be in use at any particular site.


The following configuration variables in /etc/login.defs change the behavior of this tool:


List of groups to add to the user's supplementary groups set when logging in on the console (as determined by the CONSOLE setting). Default is none.

Use with caution - it is possible for users to gain permanent access to these groups, even when not logged in on the console.

DEFAULT_HOME (boolean)

Indicate if login is allowed if we can't cd to the home directory. Default is no.

If set to yes, the user will login in the root (/) directory if it is not possible to cd to her home directory.

ENV_PATH (string)

If set, it will be used to define the PATH environment variable when a regular user login. The value is a colon separated list of paths (for example /bin:/usr/bin) and can be preceded by PATH=. The default value is PATH=/bin:/usr/bin.

ENV_SUPATH (string)

If set, it will be used to define the PATH environment variable when the superuser login. The value is a colon separated list of paths (for example /sbin:/bin:/usr/sbin:/usr/bin) and can be preceded by PATH=. The default value is PATH=/sbin:/bin:/usr/sbin:/usr/bin.

SULOG_FILE (string)

If defined, all su activity is logged to this file.

SU_NAME (string)

If defined, the command name to display when running "su -". For example, if this is defined as "su" then a "ps" will display the command is "-su". If not defined, then "ps" would display the name of the shell actually being run, e.g. something like "-sh".

SYSLOG_SU_ENAB (boolean)

Enable "syslog" logging of su activity - in addition to sulog file logging.

exit values

On success, su returns the exit value of the command it executed.

If this command was terminated by a signal, su returns the number of this signal plus 128.

If su has to kill the command (because it was asked to terminate, and the command did not terminate in time), su returns 255.

Some exit values from su are independent from the executed command:


success (--help only)


System or authentication failure


The requested command was not found


The requested command could not be executed



User account information.


Secure user account information.


Shadow password suite configuration.

see also

login , login.defs, sg , sh .

How can this site be more helpful to YOU ?

give  feedback