Story / scenario opener
You upgraded GNOME to version 46 and your dock vanished. Or you tweaked a keyboard shortcut and now Alt+Tab opens a blank window instead of switching apps. The desktop feels broken, but your files and installed packages are fine. You need a clean slate without reinstalling Fedora.
What's actually happens
GNOME does not store desktop preferences in plain text files you can edit with a text editor. It uses a binary database called DConf. Every time you change a theme, move a panel, or toggle a setting, GNOME writes a key-value pair to ~/.config/dconf/user. That file grows over time. Sometimes it accumulates stale entries, conflicting overrides, or corrupted metadata. When the database gets tangled, the desktop environment stops responding to your inputs or reverts to a safe but broken state.
Think of DConf like a version control system for your desktop. It tracks every change you make. When you reset to defaults, you are not deleting your applications or user data. You are telling GNOME to discard the local tracking database and regenerate it from the upstream schema definitions. The schema definitions live in /usr/share/glib-2.0/schemas/. They ship with the gnome-desktop3 and gnome-shell packages. They are read-only and managed by dnf. Your local database in ~/.config/ sits on top of them. Remove the local layer, and GNOME falls back to the package defaults.
The gsettings command is the user-friendly interface to that database. When you run gsettings set, it translates the command into a DConf write operation. When you run gsettings reset, it tells DConf to drop the local override and fall back to the schema default. The two tools work together. You rarely need to touch the raw DConf file unless the database itself is corrupted or locked.
The fix
Start by backing up your current state. A botched reset can wipe custom keyboard layouts and monitor profiles. Run this from your home directory terminal.
# Create a timestamped backup of the DConf database
cp ~/.config/dconf/user ~/.config/dconf/user.backup.$(date +%Y%m%d)
# Why: cp preserves permissions and gives you a single file to restore if the reset goes too far
Log out of your graphical session completely. Switching to a TTY with Ctrl+Alt+F3 is not enough. GNOME Shell keeps the DConf file locked while the session is active. If you delete it while locked, the next login will recreate a corrupted file or throw a permission error. Click your user icon and select Log Out. Wait for the login screen to appear.
Press Ctrl+Alt+F3 to drop to a virtual console. Log in with your username and password. Run the reset commands.
# Remove the user-specific DConf database
rm -f ~/.config/dconf/user
# Why: Deleting this file forces GNOME to regenerate the database from the system schemas on next login
# Reset desktop-specific overrides that sometimes survive a file deletion
gsettings reset-recursively org.gnome.desktop
gsettings reset-recursively org.gnome.shell
# Why: gsettings clears cached schema overrides in memory and writes clean defaults to the new database
GNOME extensions store their own configuration in ~/.local/share/gnome-shell/extensions. A broken extension can override desktop behavior even after a DConf reset. Remove the extension directory to guarantee a clean environment.
# Remove user-installed GNOME extensions and their configs
rm -rf ~/.local/share/gnome-shell/extensions
# Why: Extensions hook into the shell process and can persist bad state outside the DConf database
Return to the graphical login screen with Ctrl+Alt+F1. Log back in. GNOME will detect the missing configuration files and automatically recreate them with default values. Your wallpaper, dock position, and keyboard shortcuts will revert to the Fedora Workstation defaults.
Reboot before you debug. Half the time the symptom is gone.
Verify it worked
Open a terminal and check the current theme and shell state. The output should match the upstream Fedora defaults.
# Query the current GTK theme and shell mode
gsettings get org.gnome.desktop.interface gtk-theme
gsettings get org.gnome.shell.overrides enable-extensions
# Why: gsettings get reads directly from the regenerated DConf database and confirms the reset took effect
The first command should return an empty string or Adwaita. The second should return false. If you see unexpected values, the reset did not complete. Check your backup and restore it before trying again.
Run journalctl -xe to verify the shell started cleanly. Look for gnome-shell[PID]: lines. If you see Extension ... failed to load, your extension directory removal worked and the shell is running without third-party hooks. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu gnome-shell muscle-memory style to isolate desktop logs.
Common pitfalls and what the error looks like
The most common failure is a locked DConf file. If you run rm ~/.config/dconf/user while GNOME is running, the command succeeds but the next login prints a permission error in the journal. The desktop falls back to a basic fallback mode with no panel or dock. The fix is to log out completely, wait ten seconds, and delete the file again.
dconf: unable to open file: /home/user/.config/dconf/user: Permission denied
gnome-shell[1422]: Failed to load schema: org.gnome.desktop.interface
System-wide overrides persist across user resets. Administrators sometimes place custom DConf profiles in /etc/dconf/db/local.d/ or /etc/dconf/profile/. Those files apply to every user on the machine. Your local reset will not touch them. If your desktop still looks wrong after the reset, check for system-wide overrides.
# List system-wide DConf overrides
ls -l /etc/dconf/db/local.d/
# Why: Files in /etc/ override user settings and are managed by the system administrator or package maintainer
If you see configuration files there, do not delete them. They are part of the system image. Edit them with root privileges only if you understand the schema structure. Otherwise, leave them alone and accept the system defaults. Config files in /etc/ are user-modified. Files in /usr/lib/ or /usr/share/ ship with the package. Edit /etc/. Never edit /usr/lib/.
Extension conflicts are another frequent culprit. Some extensions write directly to gsettings keys instead of using the proper DConf API. They can survive a reset and immediately reapply broken values. The rm -rf ~/.local/share/gnome-shell/extensions step prevents this. If you need a specific extension, reinstall it from the GNOME Extensions website after the desktop is stable.
SELinux denials rarely cause desktop setting failures, but they do appear in the logs. If you see type=AVC msg=audit(...): avc: denied { read } for ... in journalctl -t setroubleshoot, the denial is usually about a third-party application trying to read a restricted file. It does not affect DConf. Do not disable SELinux to fix a desktop glitch. Read the one-line summary in the setroubleshoot log and fix the application permissions instead.
Trust the package manager. Manual file edits drift, snapshots stay.
When to use this vs alternatives
Use a full DConf reset when your desktop is unresponsive, themes are broken, or keyboard shortcuts stop working. Use gsettings reset for a single key when only one specific setting is misbehaving. Use dconf-editor when you need to inspect nested keys or export a subset of settings for migration. Use a fresh user account when the DConf database is corrupted beyond repair and you need to isolate the problem quickly. Stay on the upstream Workstation defaults if you only deviate from the defaults occasionally.