The scenario below assumes we booted up the computer and logged in as the user bort at the login menu. This is on 14.04.2.

If I open up a terminal, as the user bort I can list a dconf setting, for example

$ dconf read /org/compiz/profiles/unity/plugins/unityshell/launcher-hide-mode

If I were to use dconf write to change the value to 1 the menu on the left side of the screen would be hidden

$ dconf write /org/compiz/profiles/unity/plugins/unityshell/launcher-hide-mode 1
$ dconf read /org/compiz/profiles/unity/plugins/unityshell/launcher-hide-mode

Now the menu is hidden. Now lets assume I use dconf write to set it back to 0. The menu will appear again.

Now, if I was in one terminal as the user root and tried to use su bort -c to change the value for bort I CAN change it. I know this because in another terminal where I'm the user bort, I can use dconf read and see that the value has changed to 1. So the value has been changed BUT the menu on the left side of the screen is still visible. How can I make the change actually apply instead of just being updated in the dconf database? Ultimately I want to know this for use with Puppet's exec type but being able to do this as root from the terminal would be helpful towards that goal.

As root in a terminal:

# su bort -c "/bin/sh -c '/usr/bin/dconf write /org/compiz/profiles/unity/plugins/unityshell/launcher-hide-mode 1'"

As bort in a terminal after the previous command was run:

$ dconf read /org/compiz/profiles/unity/plugins/unityshell/launcher-hide-mode

Yet the menu is still there. I know this sort of question has some answers on this site, such as using dbus-launch but this hasn't worked for me. Maybe it's Ubuntu version specific?

  • Is logging out and in again an option? Alternatively, have you tried running the root command in a virtual terminal and then logging in? I suspect the reason it doesn't work is that dconf write will update the currently running session only if it has knowledge of it - which it typically won't have when you're in a root shell. It may be possible to give it knowledge of the current session, but I don't know how.
    – l0b0
    Aug 1, 2015 at 10:29

2 Answers 2


You don't have the DBUS_SESSION_BUS_ADDRESS environment variable set, so the changes don't stick. As your user, write down the output of


and then in the root command use

export DBUS_SESSION_BUS_ADDRESS=xxxxx && dconf write ...

which should work.

After fighting their lame attempt at hiding their socket for a bit, one working solution to automatically get the address is to borrow it via a process environment:

# requires a GUI session program that will always run:
p=`pgrep -u \`whoami\` gnome-panel`

r=`grep -z DBUS_SESSION_BUS_ADDRESS /proc/$p/environ | sed 's/^[^=]*=//'`

Of course you'd have to pick something other than gnome-panel if you're not running that.

Works for SSH_AUTH_SOCK as well. Just leaving this here so it may help people who have so far googled unsuccessfully (like me ;) ).

  • Thanks! This cost me so much time. I wrote with dconf and immediately read it again with dconf as root. And wondered why it does not persist over reboots, but works flawlessly with my user.
    – DBX12
    Jul 12, 2018 at 11:18

On CentOS 8.3, the following works for updating dconf settings.

$user is another user as per the title in the question above.

dbus-run-session is the recommended way to start a dbus session in command line mode. There is no need to export any DBUS_SESSION variables like BUS_ADDRESS or PID.

# start a new dbus session and execute the dconf command in bash shell
sudo  -i -u ${user} bash <<-EOF
   exec dbus-run-session -- bash -c 'dconf write /org/gnome/software/download-updates false'

To learn more, read the manpage: man dbus-run-session and man dbus-launch

I presume, this should work on Ubuntu (not tested)

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.