4

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.

  • 2
    "If I create user ID root" what? You can not create the root user, it is always there. You also don't run GUI applications as root, especially not with plain sudo. – Byte Commander Apr 2 '17 at 17:28
  • @ByteCommander At your login screen you can select your user ID or guest. You have to add user ID root to sign on as root. Also under /root/.local/share... I'm hoping gedit will create the missing user configuration files. To call gedit on system files I use pkexec personally but many use gksu which is being deprecated. Both qualify as sudo powers in my mind but if you like I'll reword the question. – WinEunuuchs2Unix Apr 2 '17 at 17:51
12

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.

0

I ended up giving up on root / sudo having it's own configuration setup for gedit. I also gave up on pkexec replacing gksu and used sudo -H instead. I then created a script to "borrow" the configuration setup from the current user to initialize:

  • Plug Ins
  • Font name and size
  • Tab Stops and convert Tabs to spaces option
  • Line Wrap vs Horizontal Scroll Bar
  • All the other current user gedit configuration settings possible

Without further ado here is the script:

#!/bin/bash

# NAME: sgedit
# PATH: /mnt/e/bin
# DESC: Run gedit as sudo using $USER preferences
# DATE: June 17, 2018.

# Must not prefix with sudo when calling script
if [[ $(id -u) == 0 ]]; then
    zenity --error --text "You cannot call this script using sudo. Aborting."
    exit 99
fi

# Get user preferences before elevating to sudo
gsettings list-recursively | grep -i gedit | grep -v history | \
    grep -v docinfo | \
    grep -v virtual-root | grep -v state.window > /tmp/gedit.gsettings

sudoFunc () {

    # Must be running as sudo
    if [[ $(id -u) != 0 ]]; then
        zenity --error --text "Sudo password authentication failed. Aborting."
        exit 99
    fi

    # Get sudo's gedit preferences
    gsettings list-recursively | grep -i gedit | grep -v history | \
        grep -v docinfo | \
        grep -v virtual-root | grep -v state.window > /tmp/gedit.gsettings.root
    diff /tmp/gedit.gsettings.root /tmp/gedit.gsettings | grep '>' > /tmp/gedit.gsettings.diff
    sed -i 's/>/gsettings set/g; s/uint32 //g' /tmp/gedit.gsettings.diff
    chmod +x /tmp/gedit.gsettings.diff
    bash -x /tmp/gedit.gsettings.diff  # Display override setting to terminal
    nohup gedit -g 1300x840+1+1220 $@ &>/dev/null &
#              Set the X geometry window size (WIDTHxHEIGHT+X+Y).

}

FUNC=$(declare -f sudoFunc)
sudo -H bash -c "$FUNC; sudoFunc $*;"

exit 0
  • You do not call the script with sudo rather use sgedit /path/to/root-owned-file
  • The command prompt returns instantly with separate gedit GUI window open
  • Change the geometry 1300x840+1+1220 to your monitor setup. Single "regular" monitor would be something like 700x400+0+0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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