Reparar un perfil de usuario dañado sin perder Escritorio y Documentos

febrero 8, 2026 • febrero 8, 2026 • Lectura: 26 min • Views: 0

¿Te fue útil?

Tu cuenta de usuario “funciona” hasta que inicias sesión. Entonces obtienes un escritorio en blanco, un bucle de inicio de sesión, Documents desaparecidos,
o aplicaciones que se bloquean como si compitieran en una carrera contra el tiempo. Eso no es un mal día. Es un día de perfil dañado.

La buena noticia: en Linux, un “perfil” es en gran parte solo archivos—dotfiles, directorios de configuración y propiedad/permiso.
La mejor noticia: tu Escritorio y Documentos suelen ser inocentes. Si dejas de improvisar y sigues un plan,
puedes arreglar la cuenta sin borrar los datos que te importan.

Qué significa realmente “perfil de usuario dañado” en Linux

En Linux, un “perfil de usuario” no es un hive del registro ni una base de datos mística. Es tu directorio home más un conjunto de
expectativas: tu UID posee tus archivos, tu shell puede leer los scripts de inicio, tu entorno de escritorio puede escribir en
la configuración y el gestor de sesión puede crear archivos temporales.

Cuando la gente dice “perfil corrupto”, normalmente se refieren a una (o más) de estas cosas:

Deriva de propiedad/permisos: tu home es propiedad de root, o tus dotfiles no son escribibles.
Presión de disco: home lleno, agotamiento de inodos o cuota excedida; las sesiones fallan de formas extrañas.
Configuración rota: un dotfile o directorio de config hace que el shell/escritorio se bloquee al inicio.
Errores del sistema de archivos: errores de metadatos en Ext4/XFS; remonte como solo lectura; errores de I/O.
Desajuste de etiquetas de seguridad: contextos SELinux incorrectos; el inicio funciona pero las apps no pueden leer/escribir.
Desajuste de UID: mismo nombre de usuario, UID diferente tras una restauración; los permisos no siguen.

“Arreglar” el perfil significa restaurar esas expectativas mientras conservas ~/Desktop y ~/Documents.
Eso requiere disciplina. La forma más rápida de perder datos es empezar a “limpiar” borrando dotfolders al azar porque un blog te lo dijo.

Guía rápida de diagnóstico (primero/segundo/tercero)

Cuando tienes prisa, no adivines. Triagúa como si estuvieras de guardia y sin dormir (porque lo estás).

Primero: ¿Puede el sistema escribir donde necesita?

¿Está / o /home lleno?
¿Está el sistema de archivos en modo solo lectura?
¿El usuario posee su directorio home y los subdirs clave?

Segundo: ¿Es un fallo de sesión/inicio causado por la configuración?

Revisa los logs del journal para la sesión del usuario.
Prueba iniciar sesión con un usuario de prueba nuevo en la misma máquina.
Prueba una sesión de shell mínima (TTY) y verifica si la cuenta en sí es viable.

Tercero: ¿El almacenamiento te está mintiendo?

Escanea errores de I/O, replays del journal de ext4, cierres de XFS, advertencias SMART.
Busca agotamiento de inodos y fallos de cuota.
Verifica la consistencia de UID entre backups/restauraciones.

Regla de decisión: si ves disco lleno o remonte como solo lectura, deja de culpar a la “corrupción del perfil” y arregla el almacenamiento primero.
Una sesión de escritorio que no puede escribir se comportará como si estuviera maldita.

Seguridad primero: preserva Escritorio y Documents antes de tocar nada

Solo tienes una oportunidad para no empeorar las cosas. Antes de “arreglar”, toma una instantánea o copia. Prefiere una copia local a otro
sistema de archivos o a un disco externo. Si no puedes, al menos crea una instantánea de solo lectura (LVM/ZFS/Btrfs) o un tarball.

Dos reglas:

No ejecutes comandos destructivos en el home del usuario hasta que tengas una copia de seguridad.
No “chmod -R 777” para salir del apuro. Eso no es una solución; es un generador de incidentes.

Broma #1: Si tu plan de recuperación es “me voy a acordar qué había en Documents”, felicitaciones—has inventado la pérdida de datos como servicio.

Tareas prácticas (con comandos, salidas y decisiones)

Las tareas abajo asumen una distribución Linux basada en systemd (Ubuntu, Debian, RHEL-like, Fedora, etc.) y un usuario llamado
alice. Ajusta nombres y rutas. Ejecuta como root o vía sudo cuando sea necesario.

Tarea 1: Confirma que el usuario existe, UID/GID y ruta de home

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

Qué significa: UID=1001, GID=1001, el directorio home es /home/alice, el shell es bash.

Decisión: Si la ruta de home es incorrecta o apunta a un directorio inexistente, arregla eso antes que nada
(problema de administración de usuarios, no “corrupción”).

Tarea 2: Comprueba espacio en disco y disponibilidad de inodos (los asesinos silenciosos)

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

Qué significa: El sistema raíz está al 99% y con inodos agotados al 100%. Eso puede romper inicios de sesión porque PAM,
los servicios de usuario de systemd y los componentes del escritorio necesitan crear archivos en /run, /tmp y logs.

Decisión: Si bytes o inodos están cerca/al 100% en montajes relevantes, libera espacio antes de tocar la configuración del perfil.
La “corrupción” puede desaparecer cuando el SO pueda respirar.

Tarea 3: Comprueba si algún sistema de archivos está en solo lectura por errores

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

Qué significa: El kernel remontó / como solo lectura debido a errores ext4. Las sesiones de usuario fallarán de formas raras e inconsistentes.

Decisión: Alto. Programa fsck en modo mantenimiento, revisa la salud del disco y trata esto como un incidente de almacenamiento primero.

Tarea 4: Busca la falla en los logs (no depures a ciegas)

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

Qué significa: La sesión no puede crear ~/.cache y luego falla GNOME Shell. Eso suele ser
propiedad/permisos, disco lleno o un home montado con opciones equivocadas.

Decisión: Ve directamente a permisos del directorio home y opciones de montaje. Resetear ajustes de GNOME no ayudará si no puede escribir.

Tarea 5: Verifica la propiedad y el modo del directorio home

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

Qué significa: Todo el directorio home es propiedad de root. El usuario no puede escribir su propia configuración o cachés.

Decisión: Arregla la propiedad. Pero hazlo con cuidado—confirma UID primero (Tarea 1), luego chown.

Tarea 6: Arregla la propiedad de forma segura (dirigido, luego amplio)

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

Qué significa: Corrigiste el nivel superior y los directorios clave de escritura primero, e identificaste archivos aún propiedad de root cerca de la superficie.

Decisión: Si la propiedad root está muy extendida y es legítima (p. ej., restaurado incorrectamente), puede que necesites un chown -R completo en el home. Si el home contiene datos compartidos o montajes especiales, detente y evalúa antes de cambios recursivos.

Tarea 7: Confirma que el usuario puede escribir en rutas críticas

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

Qué significa: El usuario puede crear archivos en ~/.cache. Eso es un requisito básico para la mayoría de escritorios.

Decisión: Si esto falla, aún tienes problemas de permisos, sistema de archivos o cuota. No sigas hasta resolverlo.

Tarea 8: Comprueba la cuota (especialmente en entornos corporativos)

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

Qué significa: El usuario está en su cuota de bloques. Las escrituras fallan con “Disk quota exceeded”, a menudo interpretado como “mi perfil está corrupto”.

Decisión: O aumentas la cuota o limpias espacio en el home del usuario. Resetear dotfiles no arreglará una cuota rígida.

Tarea 9: Identifica rápidamente los directorios más pesados (limpieza sin vandalismo)

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

Qué significa: Downloads es grande; cache es moderada. Documents es grande (y debe tratarse como datos en producción).

Decisión: Si necesitas espacio rápido, empieza por cachés y Downloads, no por Documents. Considera también limpieza a nivel de sistema si root está lleno.

Tarea 10: Haz una copia de seguridad de Escritorio y Documents (preserva metadatos)

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)

Qué significa: Copiaste los datos preservando propiedad, ACLs, xattrs y hardlinks (donde se soporta).

Decisión: Si rsync da errores por fallos de I/O, detente e investiga la salud del disco. La corrupción en esta etapa no es “config del perfil”.

Tarea 11: Busca un archivo de configuración que rompa el shell (la trampa .bashrc)

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'

Qué significa: El shell funciona sin archivos de inicio, pero falla con .bashrc. Esa es una corrupción de configuración.

Decisión: Mueve .bashrc a un lugar aparte y restaura una versión mínima conocida buena. No borres; ponlo en cuarentena.

Tarea 12: Poner en cuarentena dotfiles sospechosos (quirúrgico, 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

Qué significa: Revertiste a una línea base por defecto mientras mantienes el archivo viejo para inspección posterior.

Decisión: Si esto arregla las sesiones de terminal pero la GUI sigue fallando, el problema está en la configuración del escritorio (dconf, extensiones GNOME, etc.).

Tarea 13: Diagnostica bucle de inicio de sesión GUI comparando con un usuario nuevo

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

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

Qué significa: Creaste un usuario de prueba (contraseña bloqueada en este ejemplo; en la práctica podrías poner una o usar claves SSH).
La idea es ver si el sistema puede iniciar una sesión de escritorio para un perfil limpio.

Decisión: Si un usuario nuevo inicia sesión bien pero alice no, el problema casi seguro está dentro del home/config de Alice,
no en la pila gráfica a nivel sistema.

Tarea 14: Resetear ajustes de GNOME (dconf) sin tocar 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

Qué significa: Hiciste copia de la base dconf y la eliminaste para que GNOME recree los valores por defecto.

Decisión: Si GNOME ahora arranca, tu antiguo dconf (o una extensión) era tóxico. Reintroduce ajustes gradualmente; no restaures a ciegas.

Tarea 15: Arreglar directorios XDG del usuario (rutas de Desktop/Documents)

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"

Qué significa: El entorno de escritorio apuntaba a directorios mal escritos. Eso puede manifestarse como “Escritorio vacío” aun cuando los archivos existen.

Decisión: Si user-dirs están mal, arréglalos y crea los directorios si faltan. No muevas datos hasta que las rutas sean correctas.

Tarea 16: Comprueba y repara contextos SELinux (si aplica)

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

Qué significa: Los contextos estaban mal. SELinux puede bloquear lecturas/escrituras de formas que parecen fallos aleatorios de aplicaciones.

Decisión: Si SELinux está en modo enforcing y los contextos están mal, corrígelos antes de cambiar permisos. SELinux no se impresiona con chmod.

Tarea 17: Valida la salud del sistema de archivos (ejemplo ext4)

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

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

Qué significa: SMART dice que la unidad está bien (no es garantía), y programaste un fsck para el próximo arranque.

Decisión: Si viste errores de I/O antes, aún debes planear mantenimiento. La corrupción de perfil causada por almacenamiento inestable reaparecerá hasta que arregles la causa raíz.

Estrategia de reconstrucción limpia: nuevo usuario, migrar datos, reintroducir configuración lentamente

A veces lo más rápido no es arreglar. Es reemplazar el perfil: crea un usuario nuevo, copia los datos reales
(Desktop/Documents/etc.), y luego trae de vuelta la configuración selectivamente. Esta es la misma técnica que usan los SRE con infraestructura cattle-not-pets,
aplicada al directorio home de una persona.

Por qué funciona: un perfil de escritorio Linux acumula estado. Extensiones, cachés, ajustes de temas, sockets obsoletos,
ayudantes de autenticación, restos de aplicaciones electron, symlinks rotos y un dotfile de hace una década que olvidaste que personalizaste. Si intentas
arreglar todo in situ, perseguirás fantasmas por días. Una migración controlada te deja de sangrar.

Cómo hacerlo sin perder Escritorio/Documents

Crea un usuario nuevo (p. ej., alice2) con un home fresco.
Copia solo los “directorios de datos” primero: Desktop, Documents, Pictures, etc.
Verifica permisos e inicia sesión con el usuario nuevo.
Sólo entonces, selecciona directorios de configuración que realmente necesites (claves SSH, quizá perfil del navegador), uno a la vez.
Mantén el home viejo intacto hasta que vivas con el nuevo perfil al menos una semana.

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

Punto de decisión: Si el usuario nuevo funciona, probaste que la pila del sistema está bien y el perfil viejo era el problema. Ahora puedes
decidir mantener el usuario nuevo permanentemente o migrar de vuelta al nombre original tras la limpieza.

Qué no migrar primero

~/.cache — es literalmente cache. Déjalo regenerar.
~/.config al por mayor — aquí viven los ajustes rotos del escritorio.
~/.local/share al por mayor — parte vale la pena (fuentes, datos de apps), parte es basura. Selecciona con cuidado.
Dotfiles desconocidos de 2014 — te llevarán de vuelta a 2014, y no de forma divertida.

Broma #2: Migrar ~/.cache “para ahorrar tiempo” es como empacar la basura de la cocina para “guardar el olor.”

Notas GNOME/KDE: dconf, cachés y por qué desaparece tu escritorio

La mayoría de reportes “mi escritorio desapareció” no son un escritorio que se esfuma. Es la sesión que falla al iniciar, o que arranca
sin leer los directorios correctos. GNOME y KDE dependen de una mezcla de:

Homes escribibles para cachés y estado en tiempo de ejecución.
Daemons de sesión gestionados por unidades de systemd por usuario.
Almacenamientos de configuración (GNOME: dconf, KDE: mayormente configs de texto bajo ~/.config).
Mapeo de directorios XDG que indica a las apps dónde están Desktop y Documents.

GNOME: la base de datos dconf es un punto único de “¿por qué pasa esto?”

Los ajustes de GNOME se guardan en una base binaria dconf en ~/.config/dconf/user. Si se corrompe,
o contiene ajustes que hacen que GNOME Shell se bloquee (a menudo por extensiones), tu inicio puede quedar en bucle o en una sesión rota.

El movimiento correcto es lo que viste antes: haz respaldo, elimínala y deja que GNOME recree los valores por defecto. Luego trata las extensiones
como sospechosas. En imágenes corporativas, las extensiones suelen estar “estandarizadas”. Traducción: alguien sacó un tweak y ahora es política.

KDE Plasma: la configuración en texto facilita aislar, pero también romper

KDE guarda mucho en ~/.config como texto plano (tipo ini). Eso facilita buscar una entrada mala y arreglarla.
También facilita que scripts, gestores de dotfiles a medias y herramientas de “endurecimiento” escriban configs inválidas.

Si Plasma no arranca, culpables comunes incluyen archivos rotos como plasmashellrc, entradas de autostart, o
permisos que impiden a KDE crear sockets bajo ~/.cache o ~/.config.

Modos de falla del almacenamiento y sistema de archivos (visión SRE)

Un perfil de usuario no existe en el vacío. Está sobre almacenamiento. El almacenamiento miente de formas interesantes.

Disco lleno no es solo “no hay espacio”

Disco lleno puede significar:

Agotamiento de bloques: bytes usados, el clásico problema de df -h.
Agotamiento de inodos: demasiados archivos pequeños, la sorpresa clásica de df -i.
Agotamiento de cuota: el usuario alcanza un límite en un filesystem compartido.

Los tres pueden romper inicios de sesión, navegadores y escritorios. También pueden causar que escrituras de configuración fallen parcialmente, lo que crea
la ilusión de “corrupción” después.

Remonte en solo lectura es el kernel tocándote el hombro

Cuando ext4 detecta errores de metadatos, puede remontar solo lectura para evitar empeorar las cosas. Entonces los usuarios informan:
“Mi escritorio no guarda ajustes” o “No puedo crear archivos.” Eso no es un problema de perfil. Es el sistema de archivos protegiéndose.

Homes en red (NFS/SMB) añaden latencia y rarezas de consistencia

En entornos corporativos, los home suelen estar en NFS. Si el servidor se pone lento o la red falla, el escritorio puede colgarse durante el inicio mientras espera dotfiles,
keyrings o servicios D-Bus. Verás timeouts y errores de “stale file handle”.

Una cita operativa que deberías pegar en tu monitor

La esperanza no es una estrategia. (idea parafraseada, común en ingeniería/operaciones)

En términos de recuperación de perfiles: no “esperes” que el escritorio vuelva tras borrados aleatorios. Mide, copia, pon en cuarentena y verifica.

Tres mini-historias corporativas desde el campo

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa desplegó una política de seguridad que endureció permisos en los home de usuarios. El cambio fue simple:
“Hacer que los home no sean legibles por el resto.” Sensato. La implementación, sin embargo, asumió que todos los home vivían en disco local y que la propiedad era consistente.

En realidad, mitad de la flota usaba homes montados en red. El script de baseline se ejecutó temprano en el arranque, antes de que el montaje NFS
estuviera listo. Entonces creó amablemente /home/alice como un directorio local propiedad de root (porque el montaje no existía aún),
y luego le aplicó el nuevo modo “seguro”. Diez minutos después, NFS montó en /home, pero los directorios por usuario
ya estaban mal para algunos y correctos para otros, dependiendo del orden.

Los síntomas fueron caóticos: bucles de inicio, iconos del Escritorio faltantes y aplicaciones que se negaban a iniciar. El equipo inicialmente culpó
a una actualización de GNOME porque coincidió con el despliegue. Historia razonable, culpable equivocado.

La solución fue aburrida: orden de montaje, comprobaciones idempotentes (modificar un directorio solo si está en el filesystem previsto) y un
paso de verificación que comparaba la salida de stat con el UID/GID esperado. También dejaron de crear directorios cuando faltaba el montaje.
“Asumir” se convirtió en un verbo prohibido en las revisiones de código por un tiempo.

Mini-historia 2: La optimización que salió mal

Otra organización quería inicios más rápidos en estaciones compartidas. Alguien notó que los ~/.cache de usuarios eran grandes y
que eliminarlos parecía acelerar ciertos arranques de apps. Así que hicieron un job semanal: borrar cachés para todos los usuarios.
El job corría como root, por supuesto.

Durante unas semanas, todo parecía genial. Luego llegaron tickets: “Mi escritorio olvida mis ajustes”, “El llavero pide contraseña cada inicio”,
“El perfil del navegador se ‘repara’ solo”, “Los iconos del escritorio se reordenan”. Algunas sesiones ni siquiera arrancaban.

La causa raíz no era borrar cachés en principio. Era el cómo se hizo. El job borraba y recreaba algunos directorios,
dejándolos con propiedad de root. En el siguiente inicio, el entorno de escritorio intentó escribir en ~/.cache y falló.
Algunas apps consideraron eso fatal. Otras cayeron a valores raros por defecto.

El rollback fue inmediato: detener el job, restaurar la propiedad correcta y, si hacía falta limpiar cachés, hacerlo por usuario al inicio
con el UID correcto, o usar políticas de tmpfiles.d que no pisen la propiedad. La optimización ganó milisegundos y perdió días de productividad.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo gestionaba un pequeño entorno VDI para contratistas. Los home vivían en un array de almacenamiento compartido. La gente iniciaba sesión,
editaba documentos y se iba. Carga predecible, hasta que dejó de serlo.

Una mañana, un subconjunto de usuarios reportó que sus Documents faltaban y el Escritorio estaba vacío. El pánico subió rápido
porque “Documents faltantes” es la forma de involucrar a directivos. El ingeniero de guardia no empezó a restaurar backups.
En su lugar, siguió una lista: confirmar montajes, comprobar directorios XDG, verificar permisos y comparar contra un usuario conocido bueno.

Resultó que el almacenamiento estaba bien. Los home estaban montados. Los datos existían. El problema fue un cambio de plantillas
que desplegó un roto ~/.config/user-dirs.dirs a un subconjunto de usuarios. Desktop y Documents apuntaban a rutas mal escritas.
Los datos no se habían ido; eran los punteros.

La práctica aburrida—mantener un diagnóstico estándar de “salud de inicio de sesión” y siempre verificar rutas reales—evitó una restauración innecesaria,
evitó churn de datos en el array y mantuvo el incidente pequeño. Una línea de fix (xdg-user-dirs-update) venció a una restauración de horas que habría creado nuevos fallos.

Hechos interesantes y contexto histórico

Hecho 1: El concepto de “directorio home” de usuario viene de los primeros Unix, donde el estado por usuario vivía bajo /usr antes de que /home fuera común.
Hecho 2: Los dotfiles se convirtieron en convención porque los archivos ocultos eran una forma simple de mantener la configuración fuera de listados casuales.
Hecho 3: El dconf de GNOME reemplazó a GConf para mejorar rendimiento y centralizar el acceso a ajustes.
Hecho 4: Las especificaciones XDG de directorios base se introdujeron para reducir el caos de apps esparciendo config/estado/cache por el home.
Hecho 5: El agotamiento de inodos es un problema antiguo que se hizo más común con cachés de paquetes, node_modules y perfiles de navegador con miles de archivos pequeños.
Hecho 6: Los problemas de “bucle de inicio de sesión” a menudo involucran PAM y la creación de sesión, no la verificación de contraseña—la autenticación tiene éxito, la creación de sesión falla.
Hecho 7: Los contextos SELinux importan porque la política de seguridad puede negar acceso aun cuando los permisos Unix parezcan correctos.
Hecho 8: Los home en red se hicieron populares en empresas porque backups centralizados y perfiles móviles simplificaban la gestión, a costa de latencia y riesgos de disponibilidad.
Hecho 9: /etc/skel existe específicamente para sembrar nuevos home con dotfiles base—úsalo como tu punto de partida “conocido bueno”.

Errores comunes: síntoma → causa raíz → solución

Estos son los fallos que veo una y otra vez porque son fáciles de provocar y difíciles de reconocer.

Bucle de inicio de sesión (contraseña aceptada, vuelve a la pantalla de inicio)

Síntoma: Credenciales aceptadas, la pantalla parpadea, vuelves a GDM/SDDM.
Causa raíz: Home no escribible (permisos, cuota, remonte solo lectura), o la sesión de escritorio se bloquea al iniciar por configuración.
Solución: Revisa journalctl por “Permission denied” y “Disk quota exceeded”. Arregla primero la capacidad de escritura; luego resetea dconf o pon en cuarentena directorios de configuración del escritorio.

La carpeta Desktop aparece vacía pero los archivos existen en home

Síntoma: El Escritorio no muestra nada; la terminal muestra archivos bajo ~/Desktop u otros lugares.
Causa raíz: Mapeo XDG erróneo en ~/.config/user-dirs.dirs o discrepancia de directorios localizados.
Solución: Ejecuta xdg-user-dirs-update, verifica las rutas y asegúrate de que los directorios existen con la propiedad correcta.

Las apps se niegan a iniciar; errores mencionan cache/config

Síntoma: Navegadores/apps electron se bloquean; errores sobre ~/.cache o ~/.config.
Causa raíz: Directorios propiedad de root por scripts de limpieza equivocados o restauraciones.
Solución: chown los directorios afectados de vuelta al usuario; verifica con una prueba de escritura como el usuario.

La terminal funciona, pero el shell interactivo está roto

Síntoma: Comandos no interactivos funcionan; sesiones interactivas muestran errores.
Causa raíz: .bashrc, .profile roto, o un script del gestor de plugins que asume que existen binarios.
Solución: Empieza con bash --noprofile --norc. Pon en cuarentena los dotfiles y restaura desde /etc/skel.

Todo parece correcto, pero hay “Permiso denegado” en sistemas SELinux

Síntoma: Los permisos parecen bien; aun así “Permission denied.” Los logs de auditoría muestran denegaciones.
Causa raíz: Contexto SELinux incorrecto en el directorio home tras una restauración o copia manual.
Solución: restorecon -Rv /home/username y vuelve a probar.

La “corrupción de perfil” vuelve después de arreglarla

Síntoma: El mismo usuario se rompe otra vez semanas después.
Causa raíz: Errores subyacentes en el sistema de archivos, disco inestable, o un job de automatización recurrente que pisotea la propiedad.
Solución: Revisa dmesg, SMART, resultados de fsck y la automatización de la flota. Arregla el sistema que está rompiendo el perfil.

Listas de verificación / planes paso a paso

Checklist A: Recuperación de riesgo mínimo (mantener mismo nombre de usuario)

Inicia sesión vía TTY o SSH como admin/root (evita la sesión GUI rota por ahora).
Verifica espacio en disco e inodos en / y /home.
Comprueba remonte solo lectura y errores de I/O.
Haz backup de ~/Desktop y ~/Documents (rsync con metadatos).
Verifica propiedad y permisos del home (ls -ld y prueba de escritura como el usuario).
Pon en cuarentena solo a los sospechosos probables:
- ~/.config/dconf/user (GNOME)
- dotfiles del shell (.bashrc, .profile)
- cachés del escritorio (~/.cache) si es necesario
Corrige el mapeo XDG si Desktop/Documents están “faltando”.
Reintenta el inicio. Si funciona, reintroduce las configuraciones en cuarentena una por una.

Checklist B: Reconstrucción limpia (usuario nuevo, migrar datos)

Crea un usuario nuevo con un home fresco.
Copia solo directorios de datos (Desktop/Documents/Pictures/etc.).
Valida propiedad, inicio de sesión y comportamiento de aplicaciones.
Copia solo la configuración específica que necesitas:
- ~/.ssh (cuidado con permisos)
- directorios de apps específicos bajo ~/.config (no todo el directorio)
- selectivamente: perfiles de navegador, datos de gestores de contraseñas (solo si sabes lo que haces)
Mantén el home original como archivo hasta tener alta confianza.

Checklist C: Remediación centrada en almacenamiento (cuando el sistema es el problema)

Si el sistema de archivos está en solo lectura: detén el trabajo de recuperación del usuario; programa mantenimiento.
Ejecuta checks SMART y revisa logs del kernel por errores de I/O.
Ejecuta fsck (ext4) o la herramienta de reparación apropiada (XFS requiere manejo distinto).
Sólo después de que el almacenamiento esté estable: procede con la reparación/migración del perfil.

Preguntas frecuentes

1) ¿Qué se considera “Escritorio y Documents” en Linux?

Normalmente ~/Desktop y ~/Documents, pero los entornos de escritorio pueden seguir los mapeos XDG de
~/.config/user-dirs.dirs. Siempre revisa ese archivo antes de mover nada.

2) Si borro `~/.config`, ¿pierdo mis archivos?

No perderás Documents directamente, pero puedes perder ajustes de aplicaciones, sesiones guardadas y a veces datos de aplicaciones almacenados bajo
~/.config o ~/.local/share. No borres a lo bruto. Pon en cuarentena y restaura selectivamente.

3) ¿Por qué un sistema raíz lleno rompe el inicio de sesión de usuario?

Porque los servicios del sistema necesitan escribir estado, logs y archivos en tiempo de ejecución. Incluso si el home del usuario tiene espacio, un /
lleno puede impedir la configuración de la sesión, la activación de D-Bus o el funcionamiento de helpers de credenciales.

4) ¿Cómo sé que no es un problema del controlador gráfico?

Crea un usuario nuevo e intenta iniciar sesión. Si el usuario nuevo funciona, probablemente la pila gráfica está bien. Si nadie puede iniciar sesión,
es un problema a nivel del sistema (gráficos, gestor de pantalla o almacenamiento).

5) ¿Puedo arreglar esto reseteando permisos con `chmod -R`?

También podrías arreglar un motor ruidoso subiendo el volumen. No lo hagas. Resetear permisos sin entender propiedad, ACLs y SELinux
es cómo creas problemas de seguridad y aún así fallas en iniciar una sesión.

6) ¿Cuál es la forma más segura de “resetear” un perfil?

Crea un usuario nuevo y copia solo los directorios de datos primero. Es reversible, comprobable y evita perseguir fantasmas de configuración.

7) Mis archivos están ahí, pero no puedo abrirlos. ¿Qué hago?

Revisa la propiedad y permisos de los archivos y directorios padre, y confirma que el UID coincide con lo que la cuenta de usuario espera.
Si los archivos pertenecen a un UID viejo (tras una restauración), chown basándote en el mapeo numérico de UID.

8) ¿Cómo trato un perfil de navegador corrupto sin perder marcadores?

Haz copia de seguridad del directorio del perfil del navegador primero. Luego exporta marcadores si el navegador puede arrancar. Si no, migra solo los archivos
de la base de datos de marcadores a un perfil fresco (esto depende del navegador). Evita copiar todo el perfil roto como “solución”.

9) ¿Por qué importa tanto la propiedad de `~/.cache`?

Porque los escritorios modernos y las apps tratan los directorios de cache como espacio de trabajo escribible. Si no pueden escribir allí, fallan de formas impredecibles:
bloqueos, estado de UI faltante y bucles de arranque.

10) ¿Cuándo debo parar y restaurar desde backup?

Si ves errores de I/O durante lecturas, mensajes de corrupción del sistema de archivos o fallos repetidos al copiar datos de usuario, detente en la resolución del perfil.
Estabiliza el almacenamiento y restaura desde un backup o snapshot conocido bueno.

Conclusión: próximos pasos para mantenerte fuera de problemas

Arreglar un perfil de usuario dañado es sobre todo resistir el impulso de actuar al azar. Empieza por los cimientos: espacio en disco, inodos, remonte solo lectura,
propiedad y cuotas. Haz copia de Escritorio y Documents antes de “limpiar” nada. Luego pon en cuarentena archivos de configuración como un profesional, no como un jugador.

Pasos prácticos siguientes:

Ejecuta la guía rápida de diagnóstico y anota lo que observas (espacio, permisos, solo lectura, logs).
Haz una copia verificada de Desktop y Documents con rsync.
Arregla problemas de escritura primero (propiedad, cuotas, contextos SELinux).
Si la configuración es la culpable, resetea dconf (GNOME) o pone en cuarentena los archivos KDE específicos—un cambio a la vez.
Si sigues perdiendo tiempo, haz la reconstrucción limpia: usuario nuevo, migrar datos y reintroducir configuración deliberadamente.