Fix a Corrupted User Profile Without Losing Desktop and Documents

Your user account “works” right up until you log in. Then you get a blank desktop, a login loop, missing Documents,
or apps that crash like they’re trying to win a speedrun. That’s not a bad day. That’s a corrupted profile day.

The good news: on Linux, a “profile” is mostly just files—dotfiles, configuration directories, and ownership/permissions.
The better news: your Desktop and Documents are usually innocent bystanders. If you stop improvising and follow a plan,
you can fix the account without nuking the data you care about.

What “corrupted user profile” actually means on Linux

On Linux, a “user profile” isn’t a registry hive or a mystical database. It’s your home directory plus a set of
expectations: your UID owns your files, your shell can read startup scripts, your desktop environment can write to
config, and your session manager can create temporary files.

When people say “corrupted profile,” they usually mean one (or more) of these:

• Ownership/permission drift: Your home is owned by root, or your dotfiles are unwritable.
• Disk pressure: Home is full, inode exhaustion, or quota exceeded; sessions fail in odd ways.
• Broken config: A dotfile or config directory causes the shell/desktop to crash on startup.
• Filesystem errors: Ext4/XFS metadata errors; read-only remount; I/O errors.
• Security label mismatch: SELinux contexts wrong; login works but apps can’t read/write.
• UID mismatch: Same username, different UID after a restore; permissions don’t follow.

“Fixing” the profile means restoring those expectations while keeping your ~/Desktop and ~/Documents
intact. That requires discipline. The fastest way to lose data is to start “cleaning” by deleting random dotfolders
because a blog post told you to.

Fast diagnosis playbook (first/second/third)

When you’re in a hurry, don’t guess. Triage like you’re on-call and sleep-deprived (because you are).

First: Can the system write where it needs to?

• Is / or /home full?
• Is the filesystem read-only?
• Does the user own their home directory and key subdirs?

Second: Is it a login/session crash caused by config?

• Check journal logs for the user session.
• Try logging in with a new test user on the same machine.
• Try a minimal shell session (TTY) and see if the account itself is viable.

Third: Is storage lying to you?

• Scan for I/O errors, ext4 journal replays, XFS shutdowns, SMART warnings.
• Look for inode exhaustion and quota failures.
• Verify UID consistency across backups/restores.

Decision rule: if you see disk full or read-only remount, stop blaming “profile corruption” and fix storage first.
A desktop session that can’t write will behave like it’s cursed.

Safety first: preserve Desktop and Documents before you touch anything

You only get one chance to not make it worse. Before you “fix,” you snapshot or copy. Prefer a local copy to another
filesystem or external disk. If you can’t, at least make a read-only snapshot (LVM/ZFS/Btrfs) or a tarball.

Two rules:

1. Do not run destructive commands in the user’s home until you have a backup.
2. Do not “chmod -R 777” your way out of anything. That’s not a fix; it’s an incident generator.

Joke #1: If your recovery plan is “I’ll just remember what was in Documents,” congratulations—you’ve invented data loss as a service.

Practical tasks (with commands, outputs, and decisions)

The tasks below assume a systemd-based Linux distro (Ubuntu, Debian, RHEL-like, Fedora, etc.) and a user named
alice. Adjust names and paths. Run as root or via sudo when needed.

Task 1: Confirm the user exists, UID/GID, and home path

cr0x@server:~$ getent passwd alice
alice:x:1001:1001:Alice Example:/home/alice:/bin/bash

What it means: UID=1001, GID=1001, home directory is /home/alice, shell is bash.

Decision: If the home path is wrong or points to a non-existent directory, fix that before anything else
(user management issue, not “corruption”).

Task 2: Check disk space and inode availability (the silent killers)

cr0x@server:~$ df -h / /home
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        40G   39G  420M  99% /
/dev/sda3       200G  120G   70G  64% /home

cr0x@server:~$ df -ih / /home
Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/sda2       2.5M  2.5M     0  100% /
/dev/sda3        13M  1.2M   12M    9% /home

What it means: Root filesystem is at 99% and inode-exhausted at 100%. That can break logins because PAM,
systemd user services, and desktop components need to create files in /run, /tmp, and logs.

Decision: If either bytes or inodes are near/at 100% on relevant mounts, free space before touching profile config.
“Corruption” may vanish once the OS can breathe.

Task 3: Check if any filesystem is read-only due to errors

cr0x@server:~$ mount | egrep ' / | /home '
/dev/sda2 on / type ext4 (rw,relatime,errors=remount-ro)
/dev/sda3 on /home type ext4 (rw,relatime)

cr0x@server:~$ dmesg | tail -n 8
[12345.678901] EXT4-fs error (device sda2): ext4_find_entry:1455: inode #262210: comm systemd: reading directory lblock 0
[12345.678950] Aborting journal on device sda2-8.
[12345.679010] EXT4-fs (sda2): Remounting filesystem read-only

What it means: The kernel remounted / read-only due to ext4 errors. User sessions will fail in weird,
inconsistent ways.

Decision: Stop. Schedule fsck in maintenance mode, check disk health, and treat this as a storage incident first.

Task 4: Look for the failure in logs (don’t debug blind)

cr0x@server:~$ journalctl -b -p warning --no-pager | tail -n 15
... gdm-password][2100]: pam_unix(gdm-password:session): session opened for user alice(uid=1001) by (uid=0)
... systemd[2140]: Failed to create /home/alice/.cache: Permission denied
... gnome-session[2180]: WARNING: Application 'org.gnome.Shell.desktop' killed by signal 6
... systemd[2140]: Failed at step CHDIR spawning /usr/libexec/gnome-session-binary: Permission denied

What it means: The session is failing to create ~/.cache and then GNOME shell dies. That’s usually
ownership/permissions, disk full, or a home mounted with wrong options.

Decision: Go straight to home directory permissions and mount options. Resetting GNOME settings won’t help if it can’t write.

Task 5: Verify home directory ownership and mode

cr0x@server:~$ ls -ld /home/alice
drwxr-xr-x 42 root root 4096 Feb  4 10:31 /home/alice

What it means: The entire home directory is owned by root. The user can’t write their own config or caches.

Decision: Fix ownership. But do it carefully—confirm UID first (Task 1), then chown.

Task 6: Fix ownership safely (targeted, then broad)

cr0x@server:~$ chown alice:alice /home/alice

cr0x@server:~$ find /home/alice -maxdepth 2 -mindepth 1 -user root -print | head
/home/alice/.cache
/home/alice/.config
/home/alice/.local

cr0x@server:~$ chown -R alice:alice /home/alice/.cache /home/alice/.config /home/alice/.local

What it means: You corrected the top-level and key write-heavy directories first, and you identified remaining root-owned
files near the surface.

Decision: If root ownership is widespread and legitimate (e.g., restored from backup incorrectly), you may need a full
chown -R across the home. If the home contains shared data or special mounts, stop and evaluate before recursive changes.

Task 7: Confirm the user can write to critical paths

cr0x@server:~$ sudo -u alice -H bash -lc 'touch ~/.cache/profile_write_test && echo ok'
ok

What it means: The user can create files in ~/.cache. That’s a baseline requirement for most desktops.

Decision: If this fails, you still have permission, filesystem, or quota issues. Don’t move on yet.

Task 8: Check quota (especially in corporate environments)

cr0x@server:~$ quota -u alice
Disk quotas for user alice (uid 1001):
Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
/dev/sda3   1024000  1024000 1126400          25000   0       0

What it means: The user is at their block quota. Writes fail with “Disk quota exceeded,” often interpreted as “my profile is corrupted.”

Decision: Either raise quota or clean space in the user’s home. Resetting dotfiles won’t fix a hard quota limit.

Task 9: Identify the heaviest directories quickly (cleanup without vandalism)

cr0x@server:~$ du -xhd1 /home/alice | sort -h
120M	/home/alice/.cache
2.1G	/home/alice/.local
8.4G	/home/alice/Downloads
15G	/home/alice/Documents
26G	/home/alice

What it means: Downloads is large; cache is modest. Documents is large (and should be treated like production data).

Decision: If you need space fast, start with caches and Downloads, not Documents. Also consider system-level cleanup if root is full.

Task 10: Make a safety copy of Desktop and Documents (preserve metadata)

cr0x@server:~$ mkdir -p /root/profile-rescue/alice

cr0x@server:~$ rsync -aHAX --info=progress2 /home/alice/Desktop /home/alice/Documents /root/profile-rescue/alice/
sending incremental file list
Documents/
Documents/report.docx
         12,345,678 100%  112.34MB/s    0:00:00 (xfr#1, to-chk=0/3)
Desktop/
Desktop/todo.txt
             1,024 100%    0.01MB/s    0:00:00 (xfr#2, to-chk=0/2)

What it means: You copied the data with ownership, ACLs, xattrs, and hardlinks preserved (where supported).

Decision: If rsync errors with I/O failures, stop and investigate disk health. Corruption at this stage is not “profile config.”

Task 11: Check for a config file that breaks the shell (the .bashrc trap)

cr0x@server:~$ sudo -u alice -H bash --noprofile --norc -lc 'echo shell_ok'
shell_ok

cr0x@server:~$ sudo -u alice -H bash -lc 'echo shell_with_rc_ok'
bash: /home/alice/.bashrc: line 42: syntax error near unexpected token `fi'

What it means: The shell works without startup files, but fails with .bashrc. That’s a config corruption.

Decision: Move .bashrc aside and restore a minimal known-good version. Don’t delete; quarantine.

Task 12: Quarantine suspicious dotfiles (surgical, reversible)

cr0x@server:~$ mkdir -p /home/alice/.profile-quarantine

cr0x@server:~$ mv /home/alice/.bashrc /home/alice/.profile-quarantine/.bashrc.bad

cr0x@server:~$ cp /etc/skel/.bashrc /home/alice/.bashrc

cr0x@server:~$ chown alice:alice /home/alice/.bashrc /home/alice/.profile-quarantine/.bashrc.bad

What it means: You reverted to a default baseline while keeping the old file for later inspection.

Decision: If this fixes terminal sessions but the GUI still fails, the issue is in desktop config (dconf, GNOME extensions, etc.).

Task 13: Diagnose GUI login loop by comparing with a new user

cr0x@server:~$ useradd -m -s /bin/bash testgui

cr0x@server:~$ passwd -l testgui
passwd: password changed.

What it means: You created a test user (locked password in this example; in practice you might set one or use SSH keys).
The point is to see whether the system can start a desktop session for a clean profile.

Decision: If a new user logs in fine but alice does not, the problem is almost certainly within Alice’s home/config,
not system-wide graphics stack.

Task 14: Reset GNOME settings (dconf) without touching Documents

cr0x@server:~$ sudo -u alice -H bash -lc 'dconf dump / > /home/alice/.profile-quarantine/dconf-backup.ini'

cr0x@server:~$ sudo -u alice -H bash -lc 'rm -f ~/.config/dconf/user'

cr0x@server:~$ sudo -u alice -H bash -lc 'echo "dconf reset staged"'
dconf reset staged

What it means: You backed up the dconf database and removed it so GNOME will recreate defaults.

Decision: If GNOME now starts, your old dconf (or an extension setting) was toxic. Reintroduce settings gradually; don’t restore blindly.

Task 15: Fix broken XDG user dirs (Desktop/Documents paths)

cr0x@server:~$ sudo -u alice -H bash -lc 'cat ~/.config/user-dirs.dirs'
XDG_DESKTOP_DIR="$HOME/Desktoop"
XDG_DOCUMENTS_DIR="$HOME/Documants"

cr0x@server:~$ sudo -u alice -H bash -lc 'xdg-user-dirs-update && cat ~/.config/user-dirs.dirs'
XDG_DESKTOP_DIR="$HOME/Desktop"
XDG_DOWNLOAD_DIR="$HOME/Downloads"
XDG_TEMPLATES_DIR="$HOME/Templates"
XDG_PUBLICSHARE_DIR="$HOME/Public"
XDG_DOCUMENTS_DIR="$HOME/Documents"
XDG_MUSIC_DIR="$HOME/Music"
XDG_PICTURES_DIR="$HOME/Pictures"
XDG_VIDEOS_DIR="$HOME/Videos"

What it means: The desktop environment was pointing to misspelled directories. That can manifest as “Desktop is empty” even when files exist.

Decision: If user-dirs are wrong, fix them and create the directories if missing. Don’t move data until paths are correct.

Task 16: Check and repair SELinux contexts (if applicable)

cr0x@server:~$ getenforce
Enforcing

cr0x@server:~$ ls -Zd /home/alice
unconfined_u:object_r:default_t:s0 /home/alice

cr0x@server:~$ restorecon -Rv /home/alice | tail -n 5
restorecon reset /home/alice context unconfined_u:object_r:default_t:s0->unconfined_u:object_r:user_home_dir_t:s0
restorecon reset /home/alice/.ssh context unconfined_u:object_r:default_t:s0->unconfined_u:object_r:ssh_home_t:s0

What it means: Contexts were wrong. SELinux can block reads/writes in ways that look like random app breakage.

Decision: If SELinux is enforcing and contexts are wrong, fix contexts before changing permissions. SELinux is not impressed by chmod.

Task 17: Validate filesystem health (ext4 example)

cr0x@server:~$ smartctl -H /dev/sda
SMART overall-health self-assessment test result: PASSED

cr0x@server:~$ touch /forcefsck && echo "scheduled"
scheduled

What it means: SMART says the drive is okay (not a guarantee), and you scheduled an fsck on next boot.

Decision: If you saw I/O errors earlier, you still plan maintenance. Profile corruption caused by flaky storage will recur until you fix the root cause.

The clean rebuild strategy: new user, migrate data, reintroduce config slowly

Sometimes the fastest fix is not to fix. It’s to replace the profile: create a new user, copy the real data
(Desktop/Documents/etc.), then selectively bring back settings. This is the same approach SREs use with cattle-not-pets
infrastructure, just applied to a human’s home directory.

Here’s why this works: a Linux desktop profile accumulates state. Extensions, caches, theme settings, stale sockets,
authentication helpers, electron app goo, broken symlinks, and a decade-old dotfile you forgot you customized. If you
try to repair everything in place, you’ll chase ghosts for days. A controlled migration lets you stop the bleeding.

How to do it without losing Desktop/Documents

1. Create a new user (e.g., alice2) with a fresh home.
2. Copy only “data directories” first: Desktop, Documents, Pictures, etc.
3. Verify permissions and login with the new user.
4. Only then, cherry-pick config directories you truly need (SSH keys, maybe browser profile), one at a time.
5. Keep the old home directory intact until you’ve lived with the new profile for at least a week.

cr0x@server:~$ useradd -m -s /bin/bash alice2

cr0x@server:~$ rsync -aHAX --info=progress2 /home/alice/Documents /home/alice/Desktop /home/alice/Pictures /home/alice2/
sending incremental file list
Documents/
Desktop/
Pictures/

cr0x@server:~$ chown -R alice2:alice2 /home/alice2/Documents /home/alice2/Desktop /home/alice2/Pictures

Decision point: If the new user works, you’ve proven the system stack is fine and the old profile was the problem. Now you can
decide whether to keep the new user permanently or migrate back into the original username after cleanup.

What not to migrate first

• ~/.cache — it’s literally a cache. Let it regenerate.
• ~/.config in bulk — this is where broken desktop settings live.
• ~/.local/share in bulk — some of it is valuable (fonts, application data), some of it is junk. Cherry-pick.
• Unknown dotfiles from 2014 — they will take you back to 2014, and not in a fun way.

Joke #2: Migrating ~/.cache to “save time” is like packing your kitchen trash to “save the smell.”

GNOME/KDE specifics: dconf, caches, and why your desktop vanishes

Most “my desktop is gone” reports aren’t the desktop disappearing. They’re the desktop session failing to start, or starting
without reading the right directories. GNOME and KDE both rely on a mix of:

• Writable home directories for caches and runtime state.
• Session daemons managed by systemd user units.
• Configuration stores (GNOME: dconf, KDE: mostly text configs under ~/.config).
• XDG directory mapping that tells apps where Desktop and Documents are.

GNOME: the dconf database is a single point of “why is this happening”

GNOME settings are stored in a binary dconf database at ~/.config/dconf/user. If it becomes corrupted,
or contains settings that crash GNOME Shell (often via extensions), your login can loop or land in a broken session.

The right move is what you saw earlier: back it up, remove it, and let GNOME recreate defaults. Then treat extensions
as suspects. In corporate images, extensions are often “standardized.” Translation: someone once got a dopamine hit
from a tweak and now it’s policy.

KDE Plasma: text config makes it easier to isolate, but also easier to ruin

KDE stores a lot in ~/.config as plain text (ini-ish). That makes it easy to search for a bad entry and fix it.
It also makes it easy for scripts, half-baked dotfile managers, and “hardening” tools to write invalid configs.

If Plasma won’t start, common culprits include broken files like plasmashellrc, autostart entries, or
permissions that prevent KDE from creating sockets under ~/.cache or ~/.config.

Storage and filesystem failure modes (the SRE view)

A user profile doesn’t exist in a vacuum. It sits on storage. Storage lies in interesting ways.

Disk full isn’t just “no space left”

Disk full can mean:

• Block exhaustion: bytes used, classic df -h problem.
• Inode exhaustion: too many small files, classic df -i surprise.
• Quota exhaustion: user hits a limit on a shared filesystem.

All three can break logins, browsers, and desktops. They can also cause config writes to partially fail, which creates
the illusion of “corruption” later.

Read-only remount is the kernel tapping you on the shoulder

When ext4 detects metadata errors, it may remount read-only to avoid making things worse. Users then report:
“My desktop doesn’t save settings” or “I can’t create files.” That’s not a profile issue. That’s the filesystem protecting itself.

Network homes (NFS/SMB) add latency and consistency weirdness

In corporate environments, home directories are often on NFS. If the server gets slow or the network flakes, the desktop
can hang during login while waiting for dotfiles, keyrings, or D-Bus services to respond. You’ll see timeouts and
“stale file handle” errors.

One operational quote you should tape to your monitor

Hope is not a strategy. (paraphrased idea, common in engineering/operations)

In profile recovery terms: you don’t “hope” the desktop comes back after random deletions. You measure, copy, quarantine, and verify.

Three corporate mini-stories from the trenches

Mini-story 1: The incident caused by a wrong assumption

A company rolled out a security baseline that tightened permissions on user home directories. The change was simple:
“Make home directories not world-readable.” Sensible. The implementation, however, assumed that every home lived on
local disk and that the ownership was consistent.

In reality, half the fleet used network-mounted homes. The baseline script ran early at boot, before the NFS mount
was ready. So it helpfully created /home/alice as a local directory owned by root (because the mount wasn’t there yet),
then chmod’d it to the new “secure” mode. Ten minutes later, NFS mounted on /home, but the per-user directories
were already wrong for some users and correct for others, depending on timing.

The symptoms were chaotic: login loops, missing Desktop icons, and applications refusing to start. The team initially blamed
a GNOME update because it coincided with the rollout. Reasonable story, wrong culprit.

The fix was boring: mount ordering, idempotent checks (only modify a directory if it’s on the intended filesystem), and a
verification step that compared stat output with expected UID/GID. They also stopped creating directories when the mount was missing.
“Assume” became a banned verb in code reviews for a while.

Mini-story 2: The optimization that backfired

Another org wanted faster logins on shared workstations. Someone noticed that users’ ~/.cache directories were large and
that removing them seemed to speed up certain app startups. So they built a weekly job: wipe caches for all users.
The job ran as root, because of course it did.

For a few weeks, it looked great. Then tickets started: “My desktop forgets my settings,” “Keyring prompts every login,”
“Browser profiles keep ‘repairing’ themselves,” “Desktop icons rearranged.” A few sessions would even fail to start.

The root cause wasn’t cache clearing in principle. It was how it was done. The job deleted and recreated some directories,
leaving them owned by root. On the next login, the desktop environment tried to write to ~/.cache and failed.
Some apps treated that as fatal. Others fell back to weird defaults.

The rollback was immediate: stop the job, restore correct ownership, and if cache clearing was needed, do it per-user at login
with the correct UID, or use tmpfiles.d policies that don’t trample ownership. The performance optimization gained milliseconds
and lost days of productivity.

Mini-story 3: The boring but correct practice that saved the day

A team ran a small VDI environment for contractors. Home directories lived on a shared storage array. People logged in,
edited documents, and left. Predictable workload, until it wasn’t.

One morning, a subset of users reported that their Documents were missing and the Desktop was empty. Panic rose quickly
because “missing Documents” is how you get executives involved. The on-call engineer did not start restoring backups.
Instead, they ran a checklist: confirm mounts, check XDG dirs, verify permissions, and compare against a known-good user.

Turns out the storage was fine. The home directories were mounted. The data existed. The problem was a templating change
that had deployed a broken ~/.config/user-dirs.dirs to a subset of users. Desktop and Documents were pointing to
misspelled paths. The data wasn’t gone; the pointers were.

The boring practice—keeping a standard “login health” diagnostic and always verifying the actual file paths—prevented an unnecessary restore,
avoided data churn on the storage array, and kept the incident small. A one-line fix (xdg-user-dirs-update) beat a
multi-hour restore that would have created a whole new class of failures.

Interesting facts and historical context

• Fact 1: The concept of a user “home directory” dates back to early Unix, where user-specific state lived under /usr before /home became common.
• Fact 2: Dotfiles became a convention because hidden files were a simple way to keep configuration out of casual directory listings.
• Fact 3: GNOME’s dconf replaced older GConf approaches to improve performance and centralize settings access.
• Fact 4: XDG base directory specs were introduced to reduce the chaos of apps scattering config/state/cache across the home directory.
• Fact 5: Inode exhaustion is an old problem that got more common with the rise of package caches, node_modules, and browser profiles containing thousands of small files.
• Fact 6: “Login loop” issues often involve PAM and session setup failing, not the password check itself—authentication succeeds, session creation fails.
• Fact 7: SELinux contexts matter because the security policy can deny access even when Unix permissions look correct.
• Fact 8: Network home directories became popular in enterprises because central backups and roaming profiles simplified fleet management, at the cost of new latency and availability risks.
• Fact 9: The /etc/skel directory exists specifically to seed new home directories with baseline dotfiles—use it as your “known good” starting point.

Common mistakes: symptom → root cause → fix

These are the failures I keep seeing because they’re easy to trigger and hard to recognize.

Login loop (password accepted, returns to login screen)

• Symptom: Credentials accepted, screen flashes, you’re back at GDM/SDDM.
• Root cause: Home not writable (permissions, quota, read-only remount), or desktop session crashes on startup due to config.
• Fix: Check journalctl for “Permission denied” and “Disk quota exceeded”. Fix writeability first; then reset dconf or quarantine desktop config directories.

Desktop folder appears empty but files exist in home

• Symptom: Desktop shows nothing; terminal shows files under ~/Desktop or elsewhere.
• Root cause: Wrong XDG mapping in ~/.config/user-dirs.dirs or localized directory mismatch.
• Fix: Run xdg-user-dirs-update, verify the paths, and ensure the directories exist with correct ownership.

Apps refuse to start; errors mention cache/config

• Symptom: Browser/electron apps crash; errors about ~/.cache or ~/.config.
• Root cause: Directories owned by root due to misguided cleanup scripts or restores.
• Fix: chown the affected directories back to the user; verify with a write test as the user.

Terminal works, but interactive shell is broken

• Symptom: Non-interactive commands run; interactive sessions error out.
• Root cause: Broken .bashrc, .profile, or a plugin manager script that assumes binaries exist.
• Fix: Start with bash --noprofile --norc. Quarantine the dotfiles and restore from /etc/skel.

Everything looks correct, but access is denied on SELinux systems

• Symptom: Permissions look fine; still “Permission denied.” Audit logs show denials.
• Root cause: Wrong SELinux context on home directory after restore or manual copy.
• Fix: restorecon -Rv /home/username and re-test.

“Profile corruption” keeps coming back after you fix it

• Symptom: Same user breaks again weeks later.
• Root cause: Underlying filesystem errors, flaky disk, or a recurring automation job that tramples ownership.
• Fix: Review dmesg, SMART, fsck results, and fleet automation. Fix the system that’s breaking the profile.

Checklists / step-by-step plans

Checklist A: Minimal-risk recovery (keep same username)

1. Log in via TTY or SSH as admin/root (avoid the broken GUI session for now).
2. Verify disk space and inodes on / and /home.
3. Check for read-only remounts and I/O errors.
4. Back up ~/Desktop and ~/Documents (rsync with metadata).
5. Verify home directory ownership and permissions (ls -ld and write test as user).
6. Quarantine only the likely offenders:
   • ~/.config/dconf/user (GNOME)
   • shell dotfiles (.bashrc, .profile)
   • desktop caches (~/.cache) if needed
7. Fix XDG user dirs mapping if Desktop/Documents are “missing.”
8. Retry login. If it works, reintroduce quarantined configs one at a time.

Checklist B: Clean rebuild (new user, migrate data)

1. Create a new user with a fresh home directory.
2. Copy data directories only (Desktop/Documents/Pictures/etc.).
3. Validate ownership, login, and application behavior.
4. Copy only the specific config you need:
   • ~/.ssh (careful with permissions)
   • specific app directories under ~/.config (not the entire directory)
   • selectively: browser profiles, password manager data (only if you know what you’re doing)
5. Keep the original home directory as an archive until confidence is high.

Checklist C: Storage-first remediation (when the system is the problem)

1. If filesystem is read-only: stop user recovery work; schedule maintenance.
2. Run SMART checks and review kernel logs for I/O errors.
3. Run fsck (ext4) or appropriate repair tooling (XFS requires different handling).
4. Only after storage is stable: proceed with profile repair/migration.

FAQ

1) What counts as “Desktop and Documents” on Linux?

Typically ~/Desktop and ~/Documents, but desktop environments may follow XDG mappings from
~/.config/user-dirs.dirs. Always check that file before moving anything.

2) If I delete ~/.config, will I lose my files?

You won’t lose Documents directly, but you can lose application settings, saved sessions, and sometimes application data stored under
~/.config or ~/.local/share. Don’t delete wholesale. Quarantine and selectively restore.

3) Why does a full root filesystem break user login?

Because system services need to write state, logs, and runtime files. Even if the user’s home has space, a full /
can prevent session setup, D-Bus activation, or credential helpers from functioning.

4) How do I know it’s not a graphics driver issue?

Create a new user and try logging in. If the new user works, your graphics stack is probably fine. If nobody can log in,
it’s system-wide (graphics, display manager, or storage).

5) Can I fix this by resetting permissions with chmod -R?

You can also fix a noisy engine by turning up the radio. Don’t. Permission resets without understanding ownership, ACLs, and SELinux
are how you create security problems and still fail to boot a session.

6) What’s the safest way to “reset” a profile?

Create a new user and copy only data directories first. It’s reversible, it’s testable, and it avoids chasing config ghosts.

7) My files are there, but I can’t open them. What now?

Check ownership and permissions of the files and parent directories, and confirm the UID matches what the user account expects.
If the files belong to an old UID (after restore), chown based on numeric UID mapping.

8) How do I deal with a corrupted browser profile without losing bookmarks?

Back up the browser profile directory first. Then export bookmarks if the browser can start. If not, migrate only the bookmark database
files into a fresh profile (this is browser-specific). Avoid copying the entire broken profile as a “fix.”

9) Why does ~/.cache ownership matter so much?

Because modern desktops and apps treat cache directories as writable scratch space. If they can’t write there, they fail in unpredictable ways:
crashes, missing UI state, and startup loops.

10) When should I stop and restore from backup?

If you see I/O errors during reads, filesystem corruption messages, or repeated failures to copy user data, stop troubleshooting the profile.
Stabilize storage and restore from a known-good backup or snapshot.

Conclusion: next steps that keep you out of trouble

Fixing a corrupted user profile is mostly about resisting the urge to flail. Start with the foundations: disk space, inodes, read-only mounts,
ownership, and quotas. Back up Desktop and Documents before you “clean” anything. Then quarantine config files like a professional, not a gambler.

Practical next steps:

1. Run the fast diagnosis playbook and write down what you observe (space, permissions, read-only, logs).
2. Make a verified copy of Desktop and Documents with rsync.
3. Fix writeability problems first (ownership, quotas, SELinux contexts).
4. If config is the culprit, reset dconf (GNOME) or quarantine the specific KDE config files—one change at a time.
5. If you’re still losing time, do the clean rebuild: new user, migrate data, and only reintroduce config deliberately.