chmod 644 vs 755: ¿cuál usar en cada caso?

Al subir un proyecto a un servidor o arreglar un script que no arranca, es fácil recurrir por reflejo a 644 o 755. Son valores frecuentes, pero no son una respuesta universal. Si primero quieres descifrar los números, lee qué significa chmod 755. Aquí partimos de esa base y respondemos la pregunta práctica: ¿qué modo corresponde a un archivo y cuál a un directorio?

La regla corta

En la gran mayoría de los casos:

• Archivos normales → 644 (rw-r--r--): el propietario puede leer y escribir; los demás solo leen.
• Directorios y programas ejecutables → 755 (rwxr-xr-x): el propietario tiene control total; los demás pueden leer y entrar al directorio o ejecutar el programa, pero no modificarlo.

La diferencia es el bit de ejecución. Un archivo de datos —texto, JSON, imagen o CSS— no necesita ser ejecutable, por lo que normalmente usa 644. Un directorio o programa sí necesita ese bit.

En un directorio, x no significa “ejecutar el directorio”. Significa buscarlo o atravesarlo: poder hacer cd y llegar a elementos internos por nombre. Un directorio con 644 no tiene x. Quien tenga r puede llegar a ver los nombres de las entradas, pero no puede entrar, acceder a una entrada por nombre ni seguir hacia abajo. Por eso 644 no es un valor inicial útil para un directorio y por eso un chmod recursivo a 644 rompe un árbol. El artículo principal explica esta diferencia con más detalle.

La trampa de chmod recursivo

Un proyecto suele mezclar archivos y subdirectorios. Si intentas “arreglar los permisos” así:

chmod -R 755 myproject/    # también vuelve ejecutable cada archivo
chmod -R 644 myproject/    # quita el permiso de atravesar cada directorio

ninguno de los dos comandos expresa realmente lo que quieres. chmod -R 755 marca como ejecutables README, configuraciones y otros datos. Puede no romper nada de inmediato, pero es impreciso y complica una revisión de seguridad. chmod -R 644 es peor: deja los directorios sin x y nadie puede entrar en ellos.

Un único modo numérico absoluto no puede expresar ambas cosas. Si ya auditaste el árbol y quieres ajustar los bits rwx básicos a 644 en archivos normales y 755 en directorios, sepáralos por tipo:

# Separar archivos y directorios
find myproject -type f -exec chmod 644 {} +
find myproject -type d -exec chmod 755 {} +

# Una operación relativa distinta: añade lectura y ejecución condicional,
# pero no cambia los bits de escritura existentes
chmod -R a+rX myproject/

No son comandos equivalentes ni reparaciones universales. El par con find restablece los bits rwx básicos por tipo; a+rX es relativo y no cambia los bits de escritura existentes, por lo que un directorio que ya era 777 puede seguir siéndolo. Revisa los bits especiales por separado y excluye .env, claves privadas y credenciales de despliegue antes de ejecutarlos.

La X mayúscula es la parte importante. La x minúscula añade ejecución sin condiciones; X solo la añade a directorios o a archivos que ya tenían ejecución para alguien. Por tanto, chmod -R a+rX no vuelve ejecutables los datos, aunque sí amplía quién puede leerlos. No restablece los bits rwx básicos a un reparto 644/755: solo añade bits y conserva las escrituras existentes. Si necesitas restablecer los bits básicos por tipo, usa la separación por tipo. El calculador de chmod permite comprobar a qué modo octal equivale una operación simbólica.

Modos que realmente vas a usar

Archivos

Directorios

La idea es partir de una base habitual y ajustarla con intención. Para una sola persona, 600 o 700; para dar lectura al grupo, 640 o 750; para que el grupo también escriba, añade deliberadamente escritura de grupo con 664 o 775. Si te tienta 777, revisa primero la propiedad y los directorios padre.

De dónde salen los valores por defecto: umask

Los archivos nuevos suelen aparecer como 644 y los directorios como 755 gracias a umask. En una creación normal sin ACL predeterminada, los programas suelen solicitar 666 para archivos y 777 para directorios; umask elimina bits. Un valor común, 022, quita escritura a group y other:

• Archivo nuevo: 666 menos 022 → 644
• Directorio nuevo: 777 menos 022 → 755

En rigor, umask es una máscara de bits, no una resta: el núcleo calcula 666 & ~022. Con los valores habituales el resultado coincide con restar, pero no con uno como 023: ahí 666 & ~023 sigue siendo 644, mientras que la resta sugeriría 643.

Los archivos nuevos no son ejecutables porque el modo de partida 666 ya carece de x; umask solo puede quitar, no añadir. La ejecución se añade de forma explícita con chmod +x.

En un entorno compartido, umask 002 conserva escritura para el grupo:

• Archivo nuevo: 666 menos 002 → 664
• Directorio nuevo: 777 menos 002 → 775

Puedes previsualizarlo en el modo umask del calculador. Umask solo afecta a entradas nuevas; no reescribe lo que ya está en disco.

Un directorio compartido con 775 todavía puede tener una carencia: los archivos nuevos pertenecen al grupo principal de quien los crea, y un compañero quizá no esté en él. El bit setgid, con 2775, hace que las entradas nuevas hereden el grupo del directorio. Pero setgid solo fija el grupo; para conservar escritura de grupo también necesitas una umask como 002 o una ACL predeterminada adecuada.

Guía rápida de decisión

1. ¿Es archivo o directorio? Un archivo suele empezar en 644; un directorio, en 755.
2. ¿Debe ejecutarse? Un script o binario necesita 755, o 700 si solo lo ejecuta su propietario.
3. ¿Quién más lo necesita? Solo tú: 600/700. Tu grupo: 640/750, o 664/775 si debe escribir.
4. ¿Es recursivo? No apliques un único modo numérico absoluto a un árbol mixto. Separa tipos o usa chmod -R a+rX solo después de comprobar qué archivos hará legibles.
5. ¿Vas a usar 777? Detente: el problema suele estar en propietario, directorios padre o montaje, no en que el número sea demasiado pequeño.

Cuando distingues archivo y directorio, el resto se vuelve mucho más sencillo. Para ver un modo junto a su cadena rwxr-xr-x, o calcular el resultado de una umask, usa el calculador de chmod. Y si el modo ya es correcto y el archivo sigue sin abrirse ni ejecutarse, el problema no está en el modo: toca revisar la propiedad, los directorios padre y las capas de debajo, que es lo que recorre «permission denied» incluso después de chmod.