DEV Community

Cover image for Firefox Profiles Frozen and Corrupted on CachyOS — What Broke and How psd Was the Culprit
Musa Nayyer
Musa Nayyer

Posted on

Firefox Profiles Frozen and Corrupted on CachyOS — What Broke and How psd Was the Culprit

The Problem

Opened Firefox one morning and the profile picker showed up. Clicked my main profile — nothing happened. Hover worked, tooltips appeared, but clicks registered nowhere. Profile 1 was already dead the day before. Only the third profile (sss) responded. Main profile had six accounts in it.

What I Tried

Keyboard navigation — nothing. Tab and Enter didn't work either.

Checked the Firefox profile directory and found this:

lrwxrwxrwx  lbjm2hpz.Profile 2 -> /run/user/1000/psd/user-firefox-lbjm2hpz.Profile 2
lrwxrwxrwx  xcpk3xfu.default   -> /run/user/1000/psd/user-firefox-xcpk3xfu.default
Enter fullscreen mode Exit fullscreen mode

Symlinks. Not real directories. psd (profile-sync-daemon) moves Firefox profiles to RAM and replaces them with symlinks. The RAM targets were either empty or broken.

Ran psd preview — confirmed psd was managing both profiles. xcpk3xfu.default showed profile size 0. That profile was already gone.

Tried psd resync — ran without errors but didn't fix the picker clicks.

Tried launching directly from terminal:

firefox --profile "/home/user/.config/mozilla/firefox/lbjm2hpz.Profile 2"
firefox -P "default-release" --no-remote
MOZ_ENABLE_WAYLAND=0 firefox --profile "/home/user/.config/mozilla/firefox/lbjm2hpz.Profile 2"
Enter fullscreen mode Exit fullscreen mode

All three kept opening the sss profile instead. The --no-remote attempts threw repeated channel errors because Firefox was already running.

Checked about:profiles — confirmed the current window was actually running default-release (the main profile), but it was completely empty. No accounts, no history, nothing. The 49M of data was somewhere but Firefox wasn't seeing it.

Stopped psd, deleted the broken profile directory, tried restoring from the -backup folder — backup had disappeared when psd stopped (psd overwrites it on shutdown with whatever is in RAM). Only a crashrecovery folder from earlier that morning survived with 49M of actual data.

Restored from crashrecovery, started psd again — psd immediately created a new symlink pointing to RAM and the profile went missing again. psd was overwriting the restore on every start.

The GUI click issue turned out to be a separate Wayland input problem with the Firefox profile picker — unrelated to psd but compounding the mess.

Root Cause

psd syncs browser profiles to RAM for speed. On unclean shutdowns or crashes, the sync back to disk fails. The -backup folder gets overwritten on the next psd start with whatever empty state is in RAM. Over time this had been happening repeatedly — the profile directory had 64 crash recovery folders going back months, all showing the same pattern.

xcpk3xfu.default was already fully gone. lbjm2hpz.Profile 2 survived only because a crashrecovery snapshot existed from earlier that same day.

The Fix

Disabled Firefox in psd by adding this to ~/.config/psd/psd.conf:

BROWSERS=(google-chrome)
Enter fullscreen mode Exit fullscreen mode

Restarted psd. Firefox now reads directly from disk. No more symlinks, no more RAM sync, no more silent corruption on shutdown.

Also ran psd clean to delete the accumulated crash recovery folders and reclaim disk space.

TIL

psd is a silent data risk on systems that crash or suspend frequently — it will eat your browser profiles and leave behind only empty backup folders.

Top comments (0)