I run Ubuntu 12.04.1 LTS x64 in VirtualBox. After one very unfortunate misclick (reset saved state instead of load saved state) I got a very annoying problem.

Almost all applications (unity, synaptic, gedit, etc.) print on start:

Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications.

And all GUI settings reset after reboot.

Another symptom:

$ GSETTINGS_BACKEND=dconf dconf-editor
(dconf-editor:2353): GLib-GIO-WARNING **: Can't find module 'dconf' specified in GSETTINGS_BACKEND
GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications

But /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so is present.

What I tried (and it didn't help):

  • sudo apt-get install -f --reinstall dconf-tools libdconf0 libdconf-dbus-1-0 dconf-service
  • Build dconf-0.5 from sources and make install it
  • Create empty user profile and start programs there

I have to keep current Ubuntu installation so a complete reinstall is not an option for me.

How can I fix it?

  • 1
    I encountered the same GLib-GIO-Message when trying to use gsettings to set the Launcher position. I searched thru the forum's posts and tried the suggestions here including resetting dynamic linker configuration using ldconfig. However, all could not fix the problem. Then Dmitry's post got me thinking to use ldd to check 'gsettings' shared object dependencies, which caused me to find out the executable I was using came from that in Anaconda's installation. By using the version in /usr/bin resolved the issue.
    – panna
    Aug 7, 2017 at 4:56

7 Answers 7


This can also happen if you have PATH conflicts with a Python enviroment manager like Anaconda.

Make sure to run which gsettings before getting too deep. If that doesn't print /usr/bin/gsettings and instead something like /home/{username}/anaconda3/bin/gsettings you probably have something .profile/.bashrc/.zshrc like:

export PATH=$HOME/anaconda3/bin:$PATH

Change it to:
export PATH=$PATH:$HOME/anaconda3/bin

Appending instead of preprending to the PATH variable will solve your issue, but be aware that anything in your system bin, or other PATH locations, will supersede your anaconda3/bin.

Another option would be to alias /usr/bin/gsettings:

alias sys-gsettings=/usr/bin/gsettings
sys-gsettings get org.gnome.todo view
  • 7
    The first part (running which) is excellent advice. The second part, not so much. You generally want your environment to run using its own setup. A better, or at least alternative, solution might be to explicitly run /usr/bin/gsettings instead of messing with PATH. May 14, 2018 at 18:20
  • Yup, totally agree with you! I think overall, you should generally be aware of how the PATH is source/applied.
    – austin_ce
    Jul 9, 2018 at 15:31
  • It solved my problem in Ubuntu 18.04 very nice answer +1
    – rasul
    Sep 26, 2018 at 3:56
  • Since this is getting some traction, I think another good way might be to keep anaconda out of your path if you are having conflicts and run commands with python -m [command] [...args] instead.
    – austin_ce
    Oct 2, 2018 at 14:19
  • I had to update this in my .bashrc as well (.profile).
    – Barun
    Mar 31, 2019 at 7:31

I've found the solution. It appears that I got several custom-built libraries in /usr/local/lib that "shadowed" system libraries from /usr/lib/x86_64-linux-gnu/.

I discovered it by checking dynamic libraries loaded by libdconfsettings.so:

ldd /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so

<  several dynamic libraries from /usr/local/lib >

It happened because of the order of search paths for dynamic libraries (defined in /etc/ld.so.conf.d/). The order was the following:

  1. /lib/i386-linux-gnu
  2. /usr/lib/i386-linux-gnu
  3. /lib/i686-linux-gnu
  4. /usr/lib/i686-linux-gnu
  5. /usr/local/lib
  6. /lib/x86_64-linux-gnu
  7. /usr/lib/x86_64-linux-gnu

So if for example you put your own libc.so into /usr/local/lib it will be loaded instead of default libc.so from /lib/x86_64-linux-gnu.

The fix:

sudo mv /etc/ld.so.conf.d/libc.conf /etc/ld.so.conf.d/xuserlocal.conf
sudo ldconfig
sudo reboot
  • 2
    Thanks, I also had this problem, because I tried to develop a patch for glib and executed sudo make install. sudo make uninstall solved the problem by removing those libraries at /usr/local/lib/
    – mxmlnkn
    Apr 26, 2016 at 11:11
  • 1
    +1. Really solved a similar problem came up after installation of Glib2.
    – 111
    Oct 5, 2016 at 22:55
  • 2
    Linux Mint kept going back to default settings and not respecting any changes I made and double checked in dconf-editor. Turned out that I had built glib from source and sudo make install which I had no idea would not let me change my background or clock, or other cinnamon settings. Was driving me nuts. Back link: forums.linuxmint.com/viewtopic.php?t=244360&start=20
    – RyanNerd
    Jun 8, 2017 at 2:06
  • i get this error! mv: cannot stat '/etc/ld.so.conf.d/libc.conf': No such file or directory and i do not have any libraries in my /usr/loca/lib except the python environments i have on Anaconda. but the whole problem started when i installed a new package. and it does not happen when i run my code on jupyter-notebook instead of IDE!
    – Amir
    Jul 20, 2017 at 21:53
  • @Amir Does ldd output is the same as in issue description? Probably you have another issue.
    – Dmitry
    Jul 21, 2017 at 11:38

First check if this command returns true:

gsettings writable com.canonical.Unity.Launcher favorites

If not, install the backend with:

sudo apt-get install dconf-gsettings-backend 

If this doesn't help either, reset your profile with:

rm -rf ~/.gnome ~/.gnome2 ~/.gconf ~/.gconfd ~/.metacity .config/dconf/*

Afterwards reboot.

  • 1
    the first command returns 'true' (along with "using 'memory' backend"). Regarding removing user configuration: I already tried to create an empty profile and the problem persists even with empty user account.
    – Dmitry
    Dec 9, 2014 at 15:07
  • Do you have the dconf-gsettings-backend installed?
    – Frantique
    Dec 9, 2014 at 15:12
  • Yes, dconf-gsettings-backend is installed (and reinstalled several times).
    – Dmitry
    Dec 9, 2014 at 15:18
  • You mentioned a misclick. Where happened that?
    – Frantique
    Dec 9, 2014 at 15:26
  • 1
    Thanks for your answer. I found the solution (posted as an answer)
    – Dmitry
    Dec 9, 2014 at 15:35

Just wanted to add my personal experience on this with ubuntu 16.10. Mine stopped working after using GNOME desktop environment for a while, and then switching to Unity to show a friend how nasty it looked (IMO :D), and back to GNOME. I then started getting the "...using memory backend...".


rm -rf ~/.gnome ~/.gnome2 ~/.gconf ~/.gconfd ~/.metacity .config/dconf/*
sudo ldconfig
sudo reboot

Fixed it for me.

  • 1
    Note that this wipes all of the configuration for your desktop.
    – moorepants
    Jul 20, 2017 at 16:18

I experienced same thing in Debian Jessie. But questioner's solution (he had failed with it) was proper for my case:

 sudo apt-get install -f --reinstall  dconf-tools libdconf0 libdconf-dbus-1-0 dconf-service

This problem had been killing me, but you saved my life, Thanks :D


Make sure you have the module that does the saving (libdconfsettings.so in /usr/lib/x86_64-linux-gnu/gio/modules/ or /usr/lib/gio/modules/ or wherever you store your GIO modules). On Ubuntu that file is provided by the dconf-gsettings-backend package; reinstalling that one should suffice (sudo aptitude reinstall dconf-gsettings-backend).


This worked for me (and it does look like the same Python Anaconda issue raised by Dmitry).

$ export GIO_EXTRA_MODULES=/usr/lib/x86_64-linux-gnu/gio/modules/

(It was causing me to be unable to change gsettings - particularly printer settings for Gedit.)



You must log in to answer this question.

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