I've read the comunity "RootSudo" documentation and am interested in this line:

You should never use normal sudo to start graphical applications as Root.

Why? What is the difference? Please provide a simple explanation, as I'm just a normal desktop user.


3 Answers 3


In Ubuntu 19.10 and later, the admonition in that article (and in this answer) no longer applies. See WinEunuuchs2Unix's answer as well as this question.

Graphical applications often store settings and other user-specific data in configuration files written inside the user's home folder. The main mechanism applications use to determine what they should use as the user's home folder is the HOME environment variable. (You can inspect it yourself with echo $HOME).

Suppose you're running gedit (a graphical text editor) as root. If you run sudo gedit, HOME will continue to point toward your home directory, even though the program is running as root. Consequently, gedit will write configuration files as root into your home directory. This will sometimes result in the configuration files being owned by root and thus inaccessible to you (when you later run the program as yourself and not as root). This mainly happens when the application has to create a new configuration file. Newly created files, by default, are owned by the user who creates them (who in this case is root, not you).

That's the primary reason why you should run graphical applications with a graphical sudo frontend rather than with straight sudo. In Ubuntu and most of its derivatives (including Xubuntu and Lubuntu), the standard graphical frontend is gksu/gksudo. In Kubuntu it is kdesudo. (It depends on the desktop environment being used.)

If you want to use sudo directly to run a graphical application like gedit, you can run:

sudo -H gedit

The -H flag makes sudo set HOME to point to root's home folder (which is /root).

That still won't automatically handle the ownership of .Xauthority by copying it to a temp folder (this is the other thing that graphical sudo frontends take care of for you). But in the infrequent event that .Xauthority is inaccessible, you'll get an error saying it is, and then you can fix the problem by deleting it (sudo rm ~/.Xauthority), as it's automatically regenerated. Thus, protecting .Xauthority's ownership and permissions is less important than protecting the ownership and permissions of configuration files.

In contrast to a root-owned .Xauthority, when configuration files become owned as root, it's not always as obvious what the problem is (because graphical programs will often run, but not work very well, and output any useful errors to the console). And it's sometimes a bigger hassle to fix, especially if you're in a situation where you want one or more files in your home directory to be owned by someone other than you (because then you cannot fix it simply by recursively chowning all your files back to yourself).

Therefore, sudo (at least without -H) should not be used to run a graphical application unless you are highly familiar with the app's inner workings and know for sure that it does not ever attempt to write any configuration files.

  • Can I become the owner of all configuration files (or any files) on my Home directory again, if these file has been owned by root?
    – Nur
    Mar 20, 2013 at 4:46
  • 1
    @EliahKagan Does chmod actually do it? I always thought it was chown that did it. chmod never did it for me.
    – Wyatt Ward
    Sep 10, 2015 at 20:06
  • 3
    @Wyatt8740 I should definitely have written chown instead of chmod in my comments above. Sorry about that -- and thanks for pointing this out! Dec 31, 2016 at 23:10
  • 1
    Running sudo -H echo $HOME still returns my normal user's home and not the /root or /home/root directory (sudo version 1.8.21p2 on Linux Mint 19.1).
    – The Quark
    Jun 18, 2019 at 21:17
  • 3
    @TheQuark In sudo -H echo $HOME, your shell--running as you, not as root--performs parameter expansion on $HOME, obtaining the path of your home directory, then passes that to sudo, which in turn passes the already-expanded value to echo, which prints it. sudo -H printenv HOME, sudo -H bash -c 'echo $HOME', and sudo -H sh -c 'echo $HOME' all print /root. This is conceptually similar--though by a different mechanism--to how x=a echo "$x" doesn't print a (unless x already had the value a). Jun 18, 2019 at 21:25

Simply put:

This prevents files in your home directory becoming owned by root.

Read it here. Also, possibly a duplicate of What is the difference between "gksudo nautilus" and "sudo nautilus"?


Ubuntu 19.10 update

As of Ubuntu 19.10, typing sudo some_command now has the same effect as typing sudo -H some_command. This means the directory for any configuration files touched will be under /root directory and not /home/regular_userID directory (aka $HOME).

This makes this whole Q&A a moot point to a large degree for Ubuntu 19.10 users and greater.

To see whether sudo is working like sudo -H in your distribution try these short tests:

$ sudo printenv | grep HOME

$ sudo -H printenv | grep HOME

As you can see, sudo above does not perform like sudo -H so using plain sudo can harm your user configuration files.

An alternative to gksu nautilus, gksu gedit or sudo -H gedit is to use the nautilus-admin add-on. It allows you to browse files and directories with Nautilus and then open them as root (Administrator).

Installation is straight forward:

sudo apt install nautilus-admin

Now when you are in Nautilus you'll have an extra option to Edit as administrator:

nautilus admin.gif

gedit as root doesn't allow preferences

When you run gedit as root you can't use the preferences you've set up as a regular user for tab stops, convert tabs to spaces, font name, font size, line wrap, etc.

To solve this I've written the script sgedit to inherit user preferences and apply them to root: How can I sync my root gedit with my user gedit's preferences?

  • Call using sgedit filename1 filename2 ...
  • Gets user's gedit settings for tab stops, fonts, line-wrap, etc.
  • Elevates to sudo -H to preserve file ownership whilst getting root powers.
  • Requests password if last sudo has timed out.
  • Gets sudo's gedit settings
  • Compares differences between user and sudo gedit settings
  • Runs gsettings set on the differences only (reduces 174 set commands to a dozen or less. Next time it's run perhaps only one or two changes but often times no changes.
  • Calls gedit as a background task such that terminal prompt reappears immediately.
  • 2
    It is better not to run gedit as root at all, but use admin:///. That is actually what the nautilus-admn extension does. With a dead simple wrapper script, you can do that also easily from the command line, see my anser to askubuntu.com/questions/1191075/…
    – vanadium
    Nov 27, 2019 at 8:26
  • Just to clarify: does the above edit mean that in 19.10+ it is safe to run sudo {GUI command} now just like we would use gksudo {GUI command} before gksudo was removed?
    – TrailRider
    Jan 25, 2020 at 18:16
  • @TrailRider Yes as the top voted answer here explains in detail. Jan 25, 2020 at 18:23

You must log in to answer this question.

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