«Acceso denegado» a tus propios archivos tras reinstalar: la solución de propiedad

Qué está pasando realmente: los nombres mienten, los números no

La propiedad de archivos en Linux se almacena como identificadores numéricos: UID (identificador de usuario) y GID (identificador de grupo). La cadena “alice” es solo una búsqueda en /etc/passwd (o LDAP/SSSD). Tu archivo dice “poseído por UID 1001.” Tu sistema traduce 1001 a un nombre si puede. Tras reinstalar, “alice” podría ahora ser UID 1000, y 1001 podría pertenecer a nadie—o peor, a otra cuenta.

Entonces inicias sesión como “alice”, pero tus archivos están poseídos por “UID 1001”, y tu nueva “alice” es UID 1000. El kernel comprueba números, no sentimientos. La comprobación falla. Obtienes “Permission denied”.

Esa es la historia principal. Pero los sistemas de producción tienen giros argumentales:

• Las ACLs pueden anular los bits clásicos rwx. Puedes “poseer” el archivo y aun así que se te niegue el acceso.
• Las opciones de montaje del sistema de archivos pueden enmascarar o inventar propiedad (común en FAT/NTFS/CIFS).
• Los sistemas de archivos en red pueden reescribir la identidad (idmapping de NFS, root squash, Kerberos).
• Las capas de cifrado pueden cambiar quién puede abrir qué (eCryptfs, fscrypt; LUKS suele estar bien).
• SELinux/AppArmor puede decir “no” incluso cuando los permisos dicen “sí”.

Y sí, puedes “arreglar” esto con chmod 777. También puedes arreglar tu coche quitándole los frenos. Ambos enfoques son rápidos y educativos.

Una cita que vale la pena tener en la cabeza cuando te tienta arrasar con los permisos: «La esperanza no es una estrategia.» — Gene Kranz.

Lista rápida de diagnóstico (revisa esto primero)

Este es el camino más rápido hacia el cuello de botella. Haz esto en orden. Cada paso te dice si estás tratando con desajuste UID/GID, ACLs, semántica de montaje o capas de seguridad.

1) Confirma que el error es de permisos/propiedad y no de disco o corrupción

• Si las lecturas funcionan pero las escrituras fallan: probablemente sea propiedad/ACL/montaje en solo lectura.
• Si tanto las lecturas como los stat fallan: posiblemente un problema de montaje, falta de clave de cifrado o daño del sistema de archivos.

2) Comprueba quién eres (números) y quién posee el archivo (números)

• Si tu UID difiere del UID del archivo: tienes el clásico desajuste por reinstalación.
• Si los números coinciden pero aún así te deniegan: revisa ACLs, banderas inmutables, SELinux/AppArmor o opciones de montaje.

3) Revisa el tipo de montaje y las opciones

• FAT/NTFS/CIFS a menudo “fingen” la propiedad. Tu chown puede no hacer nada.
• NFS puede mapear identidades; la propiedad de “nobody” es una gran pista.
• Los montajes en solo lectura ocurren después de recuperaciones de journal, apagados inseguros o explícitamente con ro.

4) Revisa ACLs y atributos

• Las ACLs que deniegan son comunes en escritorios empresariales y directorios de equipo compartidos.
• El bit inmutable (chattr +i) es raro pero inolvidable.

5) Solo entonces aplica la corrección

• Prefiere chown dirigido en lugar de arrasar recursivamente.
• Prefiere cambios de propiedad numéricos cuando migras entre sistemas.
• No “arregles” montajes que no soportan propiedad forzando chown; perderás el tiempo.

Tareas prácticas: comandos, salidas, decisiones

A continuación hay tareas reales que puedes ejecutar. Cada una incluye: el comando, qué significa la salida y la decisión que tomas. Ejecútalas desde una shell con los privilegios apropiados. En caso de duda, comienza en modo solo lectura y escala con cuidado.

Task 1: Verify your current numeric identity

cr0x@server:~$ id
uid=1000(cr0x) gid=1000(cr0x) groups=1000(cr0x),27(sudo),118(lpadmin)

Meaning: Your account is UID 1000, primary GID 1000. These numbers are what the kernel uses for permission checks.

Decision: Keep these numbers handy; you’ll compare them to file ownership.

Task 2: Inspect a failing file with numeric owners

cr0x@server:~$ ls -ln /mnt/oldhome/cr0x/Documents/report.txt
-rw------- 1 1001 1001 8421 Jan 12 09:14 /mnt/oldhome/cr0x/Documents/report.txt

Meaning: The file is owned by UID 1001 and GID 1001. Your current user is 1000. This mismatch is the smoking gun.

Decision: Plan to change ownership from 1001:1001 to 1000:1000 (or to the correct target user/group).

Task 3: Confirm what UID 1001 maps to on this system

cr0x@server:~$ getent passwd 1001

Meaning: No output means UID 1001 is not assigned to any user on this system.

Decision: Safe to reassign ownership away from 1001, assuming 1001 corresponds to your old account on the old install.

Task 4: Check the filesystem type and mount options

cr0x@server:~$ findmnt -no SOURCE,FSTYPE,OPTIONS /mnt/oldhome
/dev/sdb2 ext4 rw,relatime

Meaning: ext4 supports Unix ownership and permissions. chown will work as expected.

Decision: Proceed with ownership fixes on the filesystem level.

Task 5: Detect read-only mounts (silent permission killers)

cr0x@server:~$ mount | grep ' /mnt/oldhome '
/dev/sdb2 on /mnt/oldhome type ext4 (rw,relatime)

Meaning: It’s mounted read-write (rw). If you saw ro, writes would fail regardless of ownership.

Decision: If ro, remount rw (after checking logs) instead of chasing permissions.

Task 6: Try a non-destructive write test

cr0x@server:~$ touch /mnt/oldhome/cr0x/.permtest
touch: cannot touch '/mnt/oldhome/cr0x/.permtest': Permission denied

Meaning: The directory denies write for your UID. That aligns with the ownership mismatch.

Decision: Fix ownership of the directory tree (or at least the writable paths you need).

Task 7: Check directory ownership and mode (directories are the gate)

cr0x@server:~$ ls -ldn /mnt/oldhome/cr0x
drwx------ 72 1001 1001 4096 Feb  1 18:22 /mnt/oldhome/cr0x

Meaning: Directory is 0700 owned by 1001. Only UID 1001 can read/write/enter it.

Decision: Ownership must change, otherwise nothing inside matters.

Task 8: Preview what you are about to change (find by numeric UID)

cr0x@server:~$ sudo find /mnt/oldhome/cr0x -xdev -uid 1001 -maxdepth 2 -printf '%u:%g %m %p\n' | head
1001:1001 700 /mnt/oldhome/cr0x
1001:1001 700 /mnt/oldhome/cr0x/.ssh
1001:1001 600 /mnt/oldhome/cr0x/.ssh/authorized_keys
1001:1001 644 /mnt/oldhome/cr0x/.bashrc
1001:1001 700 /mnt/oldhome/cr0x/Documents

Meaning: You’re seeing the shape of the change. The -xdev keeps you on that filesystem (important if ~/ contains mounts).

Decision: If the list looks right, proceed. If it includes unexpected paths (like mounted backups), stop and refine.

Task 9: Fix ownership safely (targeted, recursive, staying on one filesystem)

cr0x@server:~$ sudo chown -R --from=1001:1001 1000:1000 /mnt/oldhome/cr0x

Meaning: This changes ownership only if the current owner/group match 1001:1001. That prevents “oops, I changed someone else’s files.”

Decision: Use --from whenever you’re migrating ownership across reinstalls. It’s a seatbelt that actually works.

Task 10: Re-test write access

cr0x@server:~$ touch /mnt/oldhome/cr0x/.permtest
cr0x@server:~$ ls -l /mnt/oldhome/cr0x/.permtest
-rw-r--r-- 1 cr0x cr0x 0 Feb  4 10:11 /mnt/oldhome/cr0x/.permtest

Meaning: You can write now; ownership and permissions align with your current identity.

Decision: Remove the test file and proceed to validate special directories like .ssh.

Task 11: Verify and harden .ssh permissions (common post-fix breakage)

cr0x@server:~$ chmod 700 /mnt/oldhome/cr0x/.ssh
cr0x@server:~$ chmod 600 /mnt/oldhome/cr0x/.ssh/authorized_keys
cr0x@server:~$ ls -ld /mnt/oldhome/cr0x/.ssh
drwx------ 2 cr0x cr0x 4096 Feb  4 10:08 /mnt/oldhome/cr0x/.ssh

Meaning: SSH is picky; it expects tight modes. Ownership fixes sometimes leave group-write bits around, and SSH will refuse to use keys.

Decision: Normalize .ssh now so you’re not debugging “Permission denied (publickey)” later.

Task 12: Check for ACLs that can still deny access

cr0x@server:~$ getfacl -p /mnt/oldhome/cr0x/Documents | sed -n '1,20p'
# file: /mnt/oldhome/cr0x/Documents
# owner: cr0x
# group: cr0x
user::rwx
group::---
other::---
default:user::rwx
default:group::---
default:other::---

Meaning: No surprise deny ACLs here; it’s essentially 0700 semantics with default ACLs for new files.

Decision: If you see entries like user:cr0x:--- or an ACL mask restricting, fix ACLs rather than chmod’ing blindly.

Task 13: If ownership “won’t change,” confirm you’re not on NTFS/FAT or CIFS

cr0x@server:~$ findmnt -no FSTYPE,OPTIONS /mnt/share
cifs rw,relatime,vers=3.1.1,cache=strict,username=cr0x,uid=1000,gid=1000,file_mode=0644,dir_mode=0755

Meaning: CIFS presents ownership via mount options. chown typically won’t persist because the server controls it (or the client fakes it).

Decision: Fix ownership/permissions on the server side (Samba/Windows ACLs) or adjust mount options (uid=, gid=, file_mode=, dir_mode=).

Task 14: If NFS shows “nobody,” check idmapping

cr0x@server:~$ ls -ln /mnt/nfs/home/cr0x | head
drwx------  5 65534 65534 4096 Feb  3 14:20 .
drwxr-xr-x 12 65534 65534 4096 Feb  3 14:20 ..

Meaning: UID/GID 65534 is typically “nobody/nogroup.” Your client and server disagree about identity mapping.

Decision: Fix NFS idmapping (same UID/GID across systems, or proper idmapd configuration, or use NFSv4 with consistent identities).

Task 15: Check immutable attribute (the “why won’t chmod/chown work?” culprit)

cr0x@server:~$ lsattr -d /mnt/oldhome/cr0x/Documents
-------------e------- /mnt/oldhome/cr0x/Documents

Meaning: No i flag, so it’s not immutable. If you saw ----i--------, modifications would be blocked even as root.

Decision: If immutable, remove it with chattr -i (carefully, and only where justified).

Task 16: Check SELinux denials (when everything looks right but still fails)

cr0x@server:~$ getenforce
Enforcing

cr0x@server:~$ sudo ausearch -m avc -ts recent | tail -n 3
type=AVC msg=audit(1707041254.332:812): avc:  denied  { write } for  pid=2419 comm="vim" name="report.txt" dev="sdb2" ino=931281 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=file permissive=0

Meaning: SELinux is denying writes based on labels (tcontext), not Unix permissions.

Decision: Restore proper contexts (often restorecon) instead of weakening Unix permissions.

Arreglos de propiedad que no prenderán fuego a tu sistema

La corrección correcta depende de dónde vivan los archivos y cómo se crearon. Pero la regla de oro es consistente: arregla la identidad, no la tapes con parches.

El mejor escenario: sistema de archivos Linux local (ext4/xfs/btrfs)

Si tus archivos están en un sistema de archivos Linux estándar, y tu usuario obtuvo un nuevo UID tras reinstalar, tienes dos opciones limpias:

1. Cambiar el UID/GID del usuario para que coincida con los archivos (útil si tienes muchos archivos y quieres mantener la propiedad numérica estable).
2. Cambiar la propiedad de los archivos para que coincida con el nuevo UID/GID (útil si las asignaciones de UID del nuevo sistema importan o tienes múltiples usuarios).

Prefiero la opción 2 para escritorios y portátiles de un solo usuario. Prefiero la opción 1 para servidores con almacenamiento compartido, exportaciones NFS o cualquier cosa que dependa de identidad estable entre hosts.

Arreglar archivos (chown) vs arreglar la cuenta (usermod)

Opción A: Cambiar la UID de un directorio home antiguo

Ya viste el patrón más seguro: chown -R --from=OLDUID:OLDGID NEWUID:NEWGID. Es aburrido y correcto. Y eso es un cumplido.

Sé quirúrgico:

• Usa -xdev con find para evitar cruzar subárboles montados.
• Haz una vista previa (find ... -uid OLDUID) antes de mutar algo.
• No ejecutes chown -R en /. Ahí yace la locura.

Opción B: Haz que tu nuevo usuario coincida con el viejo UID/GID

Esto puede ser más limpio cuando el disco antiguo es autoritativo y quieres continuidad entre reinstalaciones.

cr0x@server:~$ id cr0x
uid=1000(cr0x) gid=1000(cr0x) groups=1000(cr0x),27(sudo)

cr0x@server:~$ sudo usermod -u 1001 cr0x
cr0x@server:~$ sudo groupmod -g 1001 cr0x

Meaning: You changed the account’s numeric identity. Existing files owned by 1000 may now be “orphaned” and need a follow-up chown from 1000 to 1001.

Decision: Only do this if 1001 is free and you understand the blast radius (services, cron jobs, containers, system users). It’s stable, but it’s not casual.

Consejo operativo: Si esto es un sistema multiusuario, coordina la asignación de UID/GID. En flotas, usa identidad centralizada (LDAP/FreeIPA/AD) o una política estricta de UID. Los usuarios locales ad-hoc son cómo terminas con “en el servidor viejo funcionaba” como estilo de vida.

Cuando chmod es la herramienta equivocada (la mayoría de las veces aquí)

chmod cambia los bits de modo. No cambia la propiedad. Si estás viendo archivos poseídos por UID 1001 y tú eres UID 1000, chmod no puede concederte propiedad. Puede conceder acceso a grupo/otros, lo cual a veces es aceptable para datos compartidos pero usualmente es una regresión de seguridad para directorios personales.

Usa chmod para lo que sirve:

• Arreglar modos de directorio rotos (falta el bit de ejecución en directorios).
• Normalizar permisos de .ssh.
• Configurar directorios de equipo con setgid para propiedad de grupo predecible.

Usa chown para arreglar “quién eres”.

Casos especiales: ACLs, NFS, Samba, FAT/NTFS, ZFS, contenedores

ACLs POSIX: la capa invisible que puede anular tus expectativas

Las ACLs añaden entradas por usuario y por grupo más allá del triplete clásico propietario/grupo/otros. También introducen una máscara que puede reducir silenciosamente los permisos efectivos.

Dolores típicos tras reinstalar:

• Hiciste chown correctamente. Aún así no puedes escribir. Una ACL deniega o la máscara restringe.
• Los archivos nuevos creados en un directorio heredan ACLs por defecto que olvidaste que existían.

El diagnóstico es simple: getfacl. La corrección depende de la intención:

• Si las ACLs eran equipaje accidental: elimínalas con setfacl -b (y quizá limpia los defaults con setfacl -k).
• Si las ACLs son deliberadas (directorio compartido): ajusta las entradas y la máscara correctamente.

NFS: la identidad debe coincidir en ambos lados

NFS no hace mágico que “cr0x” signifique lo mismo en todas partes. El NFS clásico v3 es mayormente numérico. NFSv4 puede usar nombres con idmapping, pero las malas configuraciones son comunes, especialmente tras una reinstalación donde /etc/idmapd.conf difiere por defecto.

Pistas de que estás en terreno NFS:

• Los archivos muestran UID/GID 65534 (“nobody”).
• Root no puede chown debido a restricciones del servidor.
• Los permisos varían según el host desde el que miras.

Estrategia de corrección:

• Prefiere asignaciones UID/GID consistentes entre hosts (identidad central o política local estricta).
• Verifica las opciones de exportación NFS y si root squashing está en juego.
• No “arregles” con chmod 777 en exports compartidos. Eso solo propaga el problema.

Samba/CIFS: tu UID de Linux no es el jefe aquí

Con shares SMB, el acceso está determinado en gran parte por ACLs del lado del servidor y autenticación. Las opciones de montaje del cliente pueden mapear la propiedad para mostrarla y para comprobaciones locales, pero no reescriben la idea del servidor sobre quién puede hacer qué.

Implicación: si no puedes acceder a archivos en un share Samba tras reinstalar, no empieces con chown. Comienza por:

• Credenciales y pertenencia a dominio
• Herencia de ACLs del servidor
• Opciones de montaje (uid, gid, nounix, mfsymlinks, etc.)

FAT/NTFS: los permisos son más bien una representación

FAT no tiene permisos Unix. NTFS tiene ACLs de Windows; los controladores en Linux pueden mapearlas, pero muchas configuraciones usan un modelo de permisos simplificado.

Sintomatología:

• chown devuelve “Operation not permitted” o parece funcionar pero no persiste.
• Todo muestra el propietario según el UID/GID del montaje.

Estrategia de corrección:

• Establece la propiedad mediante opciones de montaje (p. ej., uid=1000,gid=1000).
• Elige umask, fmask, dmask apropiados.
• Si necesitas semántica Unix real, copia los datos a ext4/xfs/btrfs.

ZFS: las propiedades del dataset pueden hacerte creer que estás loco

ZFS almacena la propiedad Unix normalmente, pero también tiene propiedades de dataset que afectan el comportamiento—especialmente si mezclas hosts Linux, contenedores y diferentes modos de ACL. ACLtype y ajustes de xattr pueden cambiar cómo se comportan los permisos y cómo las herramientas los reportan.

Para ZFS, trátalo como un sistema de archivos de producción real (porque lo es):

• Verifica los mountpoints del dataset y que estés corrigiendo la ruta correcta.
• Revisa el modo de ACL si ves resultados confusos.
• No hagas chown recursivo a través de datasets a menos que realmente lo quieras.

Contenedores y espacios de usuario: UID 1000 dentro no es UID 1000 fuera

Reinstalación + contenedores es donde la gente pierde tardes. Con espacios de usuario, el UID 0 de un contenedor puede mapear a un rango de UID no cero en el host. Tus archivos pueden aparecer “poseídos por 100000” o similar en el host. Eso no es corrupción; es mapeo.

Punto de decisión:

• Si quieres que host y contenedor compartan directorios escribibles, diseña el mapeo intencionalmente.
• No cambies la propiedad de rutas del host a ciegas para “arreglar” permisos de contenedores; podrías romper el mapeo y reducir la seguridad.

Broma #1: Los contenedores son geniales hasta que descubres que tu archivo está poseído por “100000” y empiezas a negociar con el kernel como si fuera un ser consciente.

Tres micro-historias corporativas desde la trinchera

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

Una compañía tenía una pequeña flota de agentes de build. Nada exótico: VMs Linux, cada una con un SSD local para workspace y un montaje NFS para cachear artefactos. Se hizo una actualización de imagen rutinaria tras un ciclo de parches de seguridad. Nuevo OS, nueva imagen base, mismos hostnames. Todos supusieron que la cuenta de usuario sería “la misma”.

No lo fue. La automatización creó el usuario de build después de un par de cuentas del sistema y lo dejó con un UID diferente al anterior. Localmente no importó mucho—workspace nuevo, archivos nuevos. En NFS, importó de inmediato. El directorio de caché estaba poseído por el UID antiguo. El usuario de build de repente no podía escribir artefactos, así que los jobs empezaron a fallar de formas que parecían errores aleatorios de compilador y timeouts. Los logs del CI estaban llenos de ruido y casi ningún mensaje de “permission denied” porque las herramientas de build reintentaban, degradaban y luego fallaban más adelante.

La respuesta inicial fue predecible: “tal vez NFS está inestable.” Alguien reinició el servicio cliente NFS. Otro remonteó el share. Eso compró minutos, a lo sumo. El fallo fue deriva de identidad, no red.

La solución fue simple y ligeramente humillante: imponer un UID consistente para el usuario de build entre imágenes, y chown del directorio de cache NFS a ese UID/GID. La lección fue más valiosa que el outage: si un recurso se comparte entre hosts, la identidad numérica debe tratarse como una API, no una coincidencia.

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

Otra organización intentó acelerar la reprovisión de estaciones. Dejaron de copiar home directories y en su lugar los movieron a un disco secundario que sobreviviría reinstalaciones del OS. “Lo montaremos en /home después de reinstalar. Fácil.”

Fue fácil—para las primeras laptops. Luego una nueva versión del OS cambió el comportamiento de creación de usuarios, y el primer usuario creado ahora cogía UID 1000, aunque IT quería otro esquema. Algunas laptops terminaron con el home antiguo poseído por UID 1005, nuevo usuario en UID 1000, y un entorno de escritorio que gestionó el desajuste fallando de maneras creativas. Bucles de login. Keyrings rotos. Aplicaciones incapaces de crear archivos de configuración. La gente perdía medio día cada una y el helpdesk desarrolló una tic nerviosa.

“Optimizaron” al saltarse un paso de migración de datos, pero también se saltaron la parte donde defines cómo persiste la identidad en el tiempo. La solución real fue incorporar una asignación predecible de UID/GID en el provisioning (o usar identidad centralizada), y añadir un paso de reconciliación de propiedad post-instalación que fuera explícito y auditado. El proceso revisado tomó unos minutos extra por máquina. Ahorró horas de caos.

Broma #2: Nada es más rápido que saltarse pasos—hasta que mides el tiempo total para deshacerlos luego.

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

Una empresa del sector financiero (es de las que adoran los trails de auditoría) tenía un entorno mixto: metal desnudo, VMs y un par de grandes servidores de archivos. Tenían una regla simple y aburrida: todos los usuarios humanos venían de un directorio central, y la creación de usuarios locales en servidores estaba desaconsejada salvo justificación. La asignación de UID/GID era consistente en cada sistema Linux.

Un fin de semana tuvieron que reinstalar un nodo de procesamiento de datos. Tenía espacio scratch local y datasets compartidos montados. La reinstalación fue fluida y el nodo volvió a unirse al cluster sin drama. No hubo errores de permisos. No hubo chown de emergencia. No hubo propiedad “nobody” misteriosa. El operador que hizo el trabajo durmió bien esa noche, lo cual en esta profesión cuenta como victoria.

La razón no fue heroísmo. Fue política. El host volvió a conectarse al servicio de directorio, obtuvo las mismas identidades numéricas y el almacenamiento compartido se comportó igual que antes. Su gestión de cambios parecía dolorosamente conservadora en tiempos normales. Bajo estrés, rindió como un seguro.

Conclusión práctica: si operas más de una máquina, identidad estable es higiene operativa. No es burocracia; es lo que evita que una reinstalación se convierta en una escena del crimen de permisos.

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

1) “chmod 777 no lo arregló”

Síntoma: Ejecutaste chmod -R 777 y aún así no puedes escribir, o algunas apps siguen fallando.

Causa raíz: Desajuste de propiedad (UID/GID), montaje en solo lectura, ACL que deniega, bit inmutable o denegación de SELinux/AppArmor.

Solución: Revisa la propiedad numérica con ls -ln, el modo de montaje con findmnt, las ACLs con getfacl, atributos con lsattr y SELinux con ausearch. Luego usa chown o corrige la capa de montaje/seguridad.

2) “chown: Operation not permitted” en tu disco externo

Síntoma: chown falla en un disco montado.

Causa raíz: El sistema de archivos no soporta semántica de propiedad Unix (FAT), o estás en CIFS/NTFS con mapeo restringido.

Solución: Usa opciones de montaje (uid=, gid=, dmask=, fmask=), o copia los datos a un sistema de archivos nativo Linux si necesitas propietarios reales.

3) “Todo está en nobody:nogroup” en NFS

Síntoma: UID/GID muestra 65534; el acceso falla.

Causa raíz: Desajuste de mapeo de identidad NFS (cliente y servidor no coinciden), o idmap mal configurado.

Solución: Asegura UID/GID consistentes entre sistemas (un directorio central ayuda), valida el dominio de idmapping de NFSv4 y vuelve a montar después de los cambios.

4) “Puedo leer pero no escribir; soy el propietario”

Síntoma: El propietario parece correcto, los bits indican escritura, pero aún así se deniega.

Causa raíz: La máscara de ACL restringe, el sistema de archivos está en solo lectura, atributo inmutable activado, o SELinux deniega.

Solución: getfacl para la máscara, findmnt para ro, lsattr para i, y revisa logs de SELinux/AppArmor.

5) “Tras arreglar la propiedad, las claves SSH dejaron de funcionar”

Síntoma: Login SSH falla con mensajes relacionados a permisos.

Causa raíz: El directorio .ssh o los archivos de llave se volvieron demasiado permisivos (escribibles por grupo), o la propiedad quedó mal.

Solución: Asegura que ~/.ssh sea 0700, las claves privadas 0600 y la propiedad coincida con el usuario.

6) “Mi sesión de escritorio está en un bucle de inicio de sesión”

Síntoma: Inicias sesión, la pantalla parpadea y vuelves a la pantalla de login.

Causa raíz: El home no es escribible para los archivos de sesión (desajuste de propiedad), o .Xauthority/.ICEauthority están poseídos por otro UID.

Solución: Arregla la propiedad del home, luego elimina/crea de nuevo los archivos de authority si hace falta.

7) “Arreglé /home, pero un subdirectorio sigue negando acceso”

Síntoma: La mayoría de cosas funcionan; un directorio de proyecto no.

Causa raíz: Otro UID/GID posee ese subárbol, o es un punto de montaje hacia otro lado, o tiene ACL restrictivas.

Solución: Usa find ... -xdev para no cruzar montajes, e inspecciona el directorio específico con ls -ldn y getfacl.

Listas de verificación / plan paso a paso

Plan A: Reinstalaste Linux y montaste tu viejo home ext4

1. Identifica tu UID/GID actual: id.
2. Identifica la propiedad antigua: ls -ldn /mnt/oldhome/you.
3. Confirma que el sistema de archivos soporta propiedad: findmnt -no FSTYPE,OPTIONS /mnt/oldhome.
4. Previsualiza el alcance: sudo find /mnt/oldhome/you -xdev -uid OLDUID | head.
5. Cambia la propiedad con un cinturón de seguridad: sudo chown -R --from=OLDUID:OLDGID NEWUID:NEWGID /mnt/oldhome/you.
6. Vuelve a probar escrituras: touch un archivo temporal.
7. Valida permisos sensibles: normaliza .ssh.
8. Revisa ACLs si queda rareza: getfacl.

Plan B: Almacenamiento compartido o múltiples hosts (NFS/cluster)

1. Para y decide: ¿quieres UID/GID estables entre hosts? Sí. Actúa como tal.
2. Elige un UID/GID autoritativo para cada cuenta humana/servicio.
3. Haz las identidades consistentes (servicio de directorio, o refuerza política local de asignación).
4. Arregla la propiedad en el servidor donde corresponda (especialmente en exports NFS).
5. Verifica desde un cliente: ls -ln debería mostrar los propietarios numéricos esperados.
6. Bloquéalo: añade comprobaciones en provisioning para confirmar UID/GID antes de montar rutas compartidas.

Plan C: Disco externo formateado como NTFS/FAT

1. Confirma el tipo de sistema de archivos: findmnt -no FSTYPE,OPTIONS /mnt/drive.
2. No luches con chown: asume que no persistirá.
3. Configura el mapeo de montaje: elige uid, gid, y máscaras que cubran tus necesidades.
4. Si necesitas semántica Unix: copia los datos a ext4/xfs/btrfs y trabaja allí.

Datos interesantes y contexto histórico

• UID/GID se almacenan como números en disco porque los primeros sistemas Unix necesitaban comprobaciones de permisos compactas y rápidas sin búsquedas de cadenas.
• Unix clásico usó UIDs de 16 bits en implementaciones tempranas; los sistemas modernos soportan rangos mucho mayores, pero las suposiciones heredadas aún aparecen en herramientas.
• El usuario “nobody” es una convención usada para mapear identidades desconocidas o no confiables (comúnmente UID 65534), especialmente en contextos NFS.
• Las ACLs POSIX se añadieron para resolver problemas multiusuario reales donde el modelo owner/group/other no era lo suficientemente expresivo para directorios compartidos.
• Setgid en directorios es un truco antiguo de colaboración que aún funciona: los archivos nuevos heredan el grupo del directorio, reduciendo incidentes de “por qué es este grupo incorrecto?”.
• NFSv4 introdujo semánticas de identidad más fuertes y operación con estado comparado con NFSv3, pero una idmapping mal configurada puede ser peor que un comportamiento numérico simple.
• FAT precede a los permisos Unix y no tiene concepto de propietarios por archivo; Linux debe proyectar un modelo de permisos encima.
• SELinux surgió de investigación en seguridad y necesidades empresariales para imponer controles de acceso obligatorios más allá de los permisos discrecionales Unix, por eso puede anular tu “chmod/chown correcto”.
• Los espacios de usuario cambiaron el juego al permitir que los contenedores remapeen UIDs, mejorando el aislamiento pero haciendo que la propiedad de archivos luzca extraña en el host.

Preguntas frecuentes

1) ¿Por qué reinstalar cambió el acceso a archivos si mi nombre de usuario es el mismo?

Porque el sistema de archivos almacena UID/GID numéricos, no el nombre de usuario. Tras reinstalar, el nombre puede mapear a un UID/GID diferente, así que el kernel te trata como un dueño distinto.

2) ¿Debo arreglar esto cambiando el UID de mi nuevo usuario o chownando los archivos?

Si es una máquina única con almacenamiento local, chownear los archivos al nuevo UID suele ser lo más sencillo. Si el almacenamiento se comparte entre máquinas, mantener UIDs estables (y cambiar la cuenta para que coincida) suele ser más seguro.

3) ¿Por qué chmod no resuelve “Permission denied” en mi caso?

Porque numéricamente no eres el propietario. chmod cambia los bits de modo, pero no la propiedad. Además, ACLs/SELinux/montajes en solo lectura pueden seguir bloqueándote.

4) ¿Cuál es la forma más segura de hacer un arreglo recursivo de propiedad?

Usa chown -R --from=OLDUID:OLDGID NEWUID:NEWGID en el directorio específico, y previsualiza con find -uid OLDUID. Añade -xdev para evitar cruzar puntos de montaje cuando uses find.

5) Ejecuté chown -R y ahora algo está roto. ¿Qué hice mal?

Víctimas comunes: subdirectorios montados (cambiaste la propiedad de otro sistema de archivos), directorios de aplicaciones que esperan cuentas de servicio específicas y permisos de claves SSH. Revisa puntos de montaje y re-verifica usuarios de servicio.

6) Mis archivos están en un disco NTFS. ¿Puedo arreglar la propiedad permanentemente?

No en el sentido Unix. Normalmente mapeas la propiedad mediante opciones de montaje. Si necesitas propiedad y modos por archivo al estilo Unix, mueve los datos a un sistema de archivos nativo Linux.

7) ¿Por qué mis archivos muestran “nobody” en NFS?

Falló el mapeo de identidad entre cliente y servidor, o el UID/GID es desconocido en un lado. Arregla haciendo las identidades consistentes o corrigiendo la configuración de idmapping de NFS.

8) Soy el propietario del directorio, pero aún no puedo escribir. ¿Qué más bloquea escrituras?

Montajes en solo lectura, restricciones de máscara de ACL, atributos inmutables, políticas de SELinux/AppArmor o límites de cuota. Diagnostica con findmnt, getfacl, lsattr y logs de seguridad.

9) ¿Puedo evitar esto por completo la próxima vez?

Sí: mantiene UIDs estables (identidad central o política de provisioning), documenta asignaciones UID/GID para cuentas de servicio y prueba montajes y propiedad después de reconstrucciones antes de entregar el sistema a usuarios.

Conclusión: próximos pasos que puedes hacer hoy

Si estás viendo “Access denied” en tus propios archivos tras una reinstalación, deja de tratarlo como un misterio de permisos. Normalmente es deriva de identidad. Los números cambiaron. El kernel está haciendo exactamente lo que le indican.

Haz esto a continuación:

1. Ejecuta id y ls -ln en una ruta con fallo. Confirma el desajuste UID/GID.
2. Confirma el tipo de sistema de archivos y las flags de montaje con findmnt. Descarta montajes en solo lectura y montajes donde la “propiedad se finge”.
3. Arregla la propiedad con chown -R --from=OLDUID:OLDGID NEWUID:NEWGID en el subtree más pequeño que tenga sentido.
4. Si el problema persiste, revisa ACLs y SELinux/AppArmor antes de empezar la “terapia chmod”.
5. En entornos compartidos, haz de la consistencia UID/GID una política, no una esperanza.

Una vez que hayas hecho esto unas cuantas veces, empezarás a reconocer su olor en segundos: mismo nombre de usuario, números distintos y un sistema de archivos que se niega cortésmente a participar en tu nostalgia.