The login loop scenario
You type your password at the GDM login screen. The screen flickers. The cursor spins for a second. Then you are back at the login prompt. You try again. Same result. You are locked out of your desktop. This is the GDM login loop. It happens after an update, a misconfigured config file, or a permission change. Your system is running, but your session cannot start.
What is actually happening
GDM is the display manager. It handles authentication and launches your desktop session. Think of GDM as a receptionist. You show your ID, the receptionist checks the list, and then points you to your office. If the office door is jammed, or the floor is flooded, the receptionist sends you back to the lobby. The login loop means authentication succeeded, but the session failed to initialize. GDM catches the crash and restarts the login screen. The error lives in the logs, not on the screen.
GDM uses PAM to authenticate. PAM checks the password and sets up the session environment. If PAM fails during session setup, GDM aborts. If the desktop environment crashes immediately after starting, GDM aborts. If a critical file in your home directory is missing or unreadable, GDM aborts. The loop is GDM trying to recover. It is not a hang. It is a rapid restart cycle.
Fedora logs everything to the journal. The journalctl command is your primary tool. Most sysadmins use journalctl -xe by muscle memory. The x flag adds explanatory priority text, and the e flag jumps to the end of the log. When debugging a boot or login issue, start with the end of the log. The error is usually the last thing that happened before the crash.
Check the logs first
Switch to a virtual terminal to access the system without a graphical session. This lets you run commands while GDM is looping.
Here's how to access a TTY and check the GDM logs for the specific failure.
# Switch to a virtual terminal to access the system without a graphical session.
# Ctrl+Alt+F3 opens TTY3. Ctrl+Alt+F2 usually returns to GDM if it is still running.
# Login with your username and password here.
# Check the disk usage. A full home partition prevents session files from being created.
# Look for 100% usage on / or /home.
df -h
# Review the GDM logs from the current boot.
# -u gdm.service filters for GDM messages.
# -e jumps to the end of the log.
# -b shows the current boot. Use -b -1 for the previous boot if the system rebooted.
journalctl -u gdm.service -e
Run journalctl first. Read the actual error before guessing.
Look for lines mentioning pam_unix, session opened, session closed, or gdm-session-worker. If you see a permission denied error on a system file, the issue is likely permissions or SELinux. If you see a syntax error in a config file, the issue is a typo in your dotfiles.
gdm-session-worker[2841]: pam_unix(gdm-password:session): session opened for user fedora(uid=1000) by (uid=0)
gdm-launch-environment[2845]: pam_env(gdm-launch-environment:session): cannot open /etc/security/pam_env.conf: Permission denied
gdm-session-worker[2841]: pam_unix(gdm-password:session): session closed for user fedora
This error means PAM cannot read system files. The session worker starts, tries to load the PAM environment, hits a permission wall, and aborts. The fix is to restore permissions or SELinux contexts on /etc.
Fix permissions and ownership
The most common cause of a login loop is broken permissions in the home directory. This often happens when a user runs a command with sudo that modifies files in /home. If you run sudo rm -rf /home/user/* instead of rm -rf /home/user/*, root owns the files. GDM authenticates as root, but the session runs as your user. If your user cannot read .Xauthority or .ICEauthority, the session crashes.
Here's how to check ownership and restore it if root took over your files.
# Check ownership of the home directory.
# GDM and the session need to read and write files here.
# If root owns your home directory, the session will fail immediately.
ls -ld /home/your_username
# Restore ownership if it is wrong.
# -R applies recursively to all files and subdirectories.
# Replace your_username with your actual account name.
sudo chown -R your_username:your_username /home/your_username
# Fix permissions on critical hidden files.
# .Xauthority and .ICEauthority must be owned by the user and not world-readable.
# 700 means only the owner can read, write, or execute.
chmod 700 /home/your_username/.Xauthority
chmod 700 /home/your_username/.ICEauthority
Check ownership before you chmod. Wrong ownership breaks more things than wrong permissions.
Handle SELinux denials
Fedora uses SELinux to enforce security policies. If you copy files from a backup, move files with cp -a, or change permissions on system directories, SELinux contexts can get corrupted. GDM checks contexts before allowing access. If the context is wrong, GDM denies access even if standard permissions look correct.
Here's how to restore SELinux contexts on your home directory safely.
# Restore SELinux contexts if they were corrupted.
# -R applies recursively. -v shows verbose output so you can see what changed.
# This is safe to run and only fixes contexts that are wrong.
# It reads the policy and sets the correct label for every file.
sudo restorecon -Rv /home/your_username
# Check for recent SELinux denials in the journal.
# -t setroubleshoot filters for the SELinux troubleshoot daemon.
# This often provides a one-line summary of what was denied and why.
journalctl -t setroubleshoot -e
Restore contexts, do not disable SELinux. A disabled policy hides the real problem.
Clear corrupted session files
Session files like .Xauthority store authentication cookies for the display server. If these files get corrupted, or if you switch between display managers, the session can fail to authenticate with the display server. GDM recreates these files automatically. Removing them forces a fresh start.
Here's how to remove corrupted session files and force GDM to regenerate them.
# Remove the Xauthority file if it is corrupted.
# GDM recreates this file automatically on the next login.
# A corrupted file causes the session to abort immediately.
rm ~/.Xauthority
# Remove the ICEauthority file if it exists and is suspected to be bad.
# This is less common but can cause similar issues with inter-client exchange.
rm ~/.ICEauthority
# Check for syntax errors in user profile scripts.
# A typo in ~/.bashrc or ~/.profile can break the session startup script.
# The shell will refuse to start, and GDM will loop.
bash -n ~/.bashrc
bash -n ~/.profile
If bash -n reports a syntax error, edit the file to fix the typo. The session cannot start if the shell configuration is invalid.
Recover from a full disk
If your disk is full, the session cannot create temporary files or write to the journal. GDM will fail to start the session and loop. This often happens after a large download, a log explosion, or a failed package manager transaction.
Here's how to check disk usage and free space if the partition is full.
# Check disk usage on all mounted filesystems.
# Look for 100% usage on / or /home.
# The Use% column shows the percentage of space used.
df -h
# Find large files in the home directory if /home is full.
# -type f limits search to files.
# -size +1G finds files larger than 1 gigabyte.
# This helps identify downloads or logs consuming space.
find /home/your_username -type f -size +1G -exec ls -lh {} \;
# Remove large unnecessary files to free space.
# Be careful to only delete files you know are safe to remove.
rm /home/your_username/Downloads/large_file.iso
Free space before you debug. A full disk causes cascading failures that look like unrelated errors.
Verify the fix
After applying the fix, restart GDM to test the login. You can also reboot the system. Restarting GDM is faster and isolates the fix to the display manager.
Here's how to restart GDM and test the login without a full reboot.
# Restart GDM to test the fix without a full reboot.
# This drops the current session and brings back the login screen.
# If the fix worked, you should be able to log in normally.
sudo systemctl restart gdm
# Check the status of GDM to ensure it is active.
# This shows if the service is active, failed, or restarting.
# The output includes recent log lines and the exit code if it failed.
systemctl status gdm
Reboot before you declare victory. Some session state persists across GDM restarts.
Common pitfalls
Disabling SELinux with setenforce 0 might fix the login loop temporarily. This is a band-aid. It hides the permission or context issue. When you reboot, SELinux re-enforces, and the loop returns. Use restorecon to fix the root cause.
Running chmod 777 on your home directory fixes permission errors but creates a security risk. Other users on the system can read your files. Use chown to fix ownership and chmod 700 for private directories.
Editing files in /usr/lib instead of /etc causes drift. Packages overwrite /usr/lib on updates. Your changes disappear. Always edit configuration in /etc. Fedora follows the convention that /etc is for user modifications and /usr/lib is for package defaults.
Decision matrix
Use restorecon -Rv /home/username when SELinux contexts are wrong or you moved files with cp -a instead of mv.
Use rm ~/.Xauthority when the session crashes immediately with no clear error and you recently changed display managers.
Use chown -R user:user /home/user when the home directory ownership changed to root after a misused sudo command.
Use df -h when the system feels sluggish and the login loop started after filling the disk with logs or downloads.
Use journalctl -u gdm.service -e when you need to find the root cause before applying a fix.
Use sudo systemctl restart gdm to test a fix quickly without rebooting the entire machine.