Create user ID `root` to force `gedit` to create user configuration file

When using sudo powers and calling gedit the top level menu with File Edit View Search Tools Documents Help is missing.

If I create user ID root and sign in once and call gedit will it create the necessary user configuration files that might fix this?

Will this also make the annoying error messages go away whenever I use sudo, gksu or pkexec as a regular user with elevated privileges togedit ?

Will there be other benefits with Nautilus and other Gnome derivative Ubuntu applications?

NOTE: by sudo powers you can google pkexec gedit 3.5k hits, gksu gedit 40k hits or sudo gedit 500k hits. I'm in the minority using the first method but I believe it will become the standard in Ubuntu 17.04.

June 12, 2017 Update Here are a list of errors you get when using pkexec gedit:

(gedit:13003): Gtk-WARNING **: Calling Inhibit failed: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files

** (gedit:13003): WARNING **: Set document metadata failed: Setting attribute metadata::gedit-spell-enabled not supported

** (gedit:13003): WARNING **: Set document metadata failed: Setting attribute metadata::gedit-encoding not supported

** (gedit:13003): WARNING **: Set document metadata failed: Setting attribute metadata::gedit-position not supported

On this bug report there is a commitment to fix these distracting messages as of June 5, 2017. No indication is given for when the fix will be upstream nor if the functionality will be implemented or the error messages will simply disappear.

Note the bug report was filed over a year ago and over that time it only effects 18 people.

Once again, with feeling. DO NOT USE GRAPHICAL APPLICATIONS AS ROOT!

Now, there are some exceptions to the above rule. For example, any part of the Ubuntu control panel that requests root is generally safe, but only because it only keeps the privileges for as long as it needs to, at which point it will immediately dump them back to normal mode. Similarly, they're also specially designed to use root effectively and in a way that won't break things. In short, everything gedit and most other applications do not do.

If you really need gedit to have its own configuration in the /root folder, launch it like so:

sudo -i gedit

However, this still won't work for a number of reasons. Your menubar being gone is more or less a side effect of how Ayatana's menu system works. In short, the system is trying to create menu objects for/owned by the root user, which causes things to decidedly break.

You can get around the lack of a menu by using sudo's -E flag, but that will still cause DBus/DConf/whatever to be annoyed at you. In this mode, the menu will be embedded into gedit's window directly, because we still can't get a link to DBus/Ayatana.

This echoes the sentiment of the Ubuntu developers and is not a bug. They are of the opinion that the GUI is effectively "easy mode", and root access is effectively not "easy mode." If you want root, go to the terminal and use it there. In fact, this is pretty much a valid form of resistance -- if you can't use nano to edit files, you shouldn't be poking around as the root user.

If you absolutely must use root under the GUI (which I highly advise you not do, even as its own user), create a file called /etc/lightdm/lightdm.conf and put this into that file:

[SeatDefaults]
greeter-show-manual-login=true

Restart the lightdm service by using sudo systemctl restart lightdm.service and you should be able to login as root. If you don't use lightdm, find and follow the instructions respective to that display manager.

You'll also need to re-enable the root account, which you can do by simply running the following command:

sudo passwd root

Be sure you choose a very strong password, as this will allow root logins to your system. Note that this is also against every recommendation out there because sudo exists and is much safer/less likely to let you accidentally break something.

On that note, when you actually do this, gedit will work as root (as you expect) in the root user session. However, the second you come back to your main session, it will still refuse to work (for the reasons listed above).

The root account should not be used to bypass the much-hated Permission denied error willy-nilly. Think of that message as the following:

Hey, what you're doing might have severe side effects on your system. Think very carefully and double-check your command to make sure you're doing exactly what you're intending to do. If you're sure this is what you want to do, escalate to the lowest possible privilege level that can be used to do what you want.

Even so, see if there's a solution that doesn't involve escalating to a privileged account. It's much easier to delete and recreate a broken user than it is to recreate a broken system.