Keyboard Shortcuts Dead After Linux Update? Here's the Fix

Quick answer: Run dconf reset -f /org/gnome/desktop/wm/keybindings/ and reboot. If that doesn't cover it, blow away ~/.config/dconf/user after backing up your other settings.

Why Your Shortcuts Flaked Out

You did an update — probably a point release on Ubuntu 24.04 or Fedora 40 — and suddenly your keyboard shortcuts are dead. Ctrl+Alt+T does nothing. Alt+F2 doesn't launch the run dialog. Super+Space for the app launcher? Gone.

This happens because GNOME (and sometimes KDE) stores keyboard shortcuts in your user-level dconf database. An update can corrupt a keybinding schema or change the path where it expects to find those settings. I've seen this on Ubuntu 22.04 after a kernel update, on Fedora 38 after a GNOME 44 upgrade, and even on Pop!_OS after a COSMIC update. The symptoms are identical: the shortcuts you set are there in Settings → Keyboard, but they don't actually fire.

Fix Steps (Start Here)

1. Close all running apps. Especially the Settings window. We want no lock on the dconf database.
2. Open a terminal. If you can't get one via shortcut, use Ctrl+Alt+F2 to switch to a TTY, log in, and run export DISPLAY=:0 before the reset command.
3. Reset GNOME keybinding schemas:

   dconf reset -f /org/gnome/desktop/wm/keybindings/
   dconf reset -f /org/gnome/shell/keybindings/
   dconf reset -f /org/gnome/mutter/keybindings/

   This clears only the shortcut settings, leaving your theme, wallpaper, and app preferences intact.
4. Reboot. Yes, a full reboot. A logout works sometimes, but I've had it fail. Reboot guarantees the dconf service reloads the clean schema.
5. Test. Try Super+Space or Ctrl+Alt+T. If they work, go re-set your custom shortcuts in Settings → Keyboard. If not, move to the alternative fixes below.

If That Didn't Work

Nuke the dconf user database

Sometimes the corruption goes deeper — it's in the binary user file itself. I had a client last month whose entire GNOME session was borked after a dconf upgrade. The fix was nuclear but safe:

cp ~/.config/dconf/user ~/.config/dconf/user.backup
rm ~/.config/dconf/user

Log out and back in. You'll lose all GNOME settings — wallpapers, dock config, theme tweaks — but shortcuts will come back to factory defaults. You can then restore other settings from user.backup using dconf load if you're brave, but honestly, I'd just rebuild them. It's faster than hunting down which key is corrupt.

Check if a specific app is stealing the shortcut

This is rare but real. I once had a buggy version of gnome-terminal that grabbed Ctrl+Alt+T internally and refused to pass it to the window manager. Try opening the app that your shortcut should launch, check its own keyboard preferences, and disable any conflicting bindings.

If you're on Xfce or KDE

• Xfce: Run xfce4-settings-manager → Keyboard → Application Shortcuts. Look for a blank entry or a duplicate. Delete the bad one and reassign.
• KDE: Go to System Settings → Shortcuts. Sometimes a schema upgrade adds a new default shortcut that conflicts with your custom one. Remove the new one, then reapply yours.

Prevention: Lock Your Shortcuts After Tweaking

Once you get everything working, make a backup of your keybinding configuration. It's a one-liner:

dconf dump /org/gnome/desktop/wm/keybindings/ > ~/keybindings-backup.conf

Or if you want the whole GNOME shell settings (not just shortcuts):

dconf dump /org/gnome/shell/ > ~/shell-backup.conf

Store that file somewhere safe — cloud sync folder, email it to yourself, whatever. After the next update, if shortcuts break again, restore with:

dconf load /org/gnome/desktop/wm/keybindings/ < ~/keybindings-backup.conf

I've been doing this for years. Never lost a shortcut since.

One last thing: if you're running a rolling release like Arch or Tumbleweed, this will happen more often. Don't fight it — automate the backup with a cron job or a systemd timer that runs weekly. Future you will thank present you.