umask<\/code> (user file-creation mode mask) es la m\u00e1scara de permisos<\/strong> que se aplica en el momento de crear<\/em> un archivo o directorio. No cambia lo que ya existe; influye en c\u00f3mo \u201cnacen\u201d<\/strong> los nuevos objetos del sistema de archivos.<\/p>\n\n\n\nEn mi experiencia, cuando varias personas trabajan en el mismo servidor o carpeta compartida, una umask bien pensada te ahorra roces y tickets<\/strong>. Me he repetido mil veces que, en Linux, \u201ctodo es archivo o directorio\u201d; por eso, los permisos por defecto importan tanto como los que ajustas despu\u00e9s<\/strong>. Si tu equipo colabora y la umask es demasiado restrictiva, rompes el flujo<\/strong> (nadie puede editar lo reci\u00e9n creado). Si es demasiado laxa, abres puertas<\/strong> que no quer\u00edas abrir.<\/p>\n\n\n\n![\"servidores](\"https:\/\/www.hostingtg.com\/blog\/wp-content\/uploads\/2025\/09\/servidores-vps-easypanel.webp\" "\\"\\"")
<\/figure>\n\n\n\nConceptualmente, las aplicaciones suelen pedir permisos \u201cbase\u201d:<\/p>\n\n\n\n
\n- Archivos<\/strong>: 666 (rw-rw-rw-) \u2192 por defecto no<\/em> se da
x<\/code> a los archivos.<\/li>\n\n\n\n- Directorios<\/strong>: 777 (rwxrwxrwx).<\/li>\n<\/ul>\n\n\n\n
Luego entra umask<\/code> y quita<\/strong> bits. Por eso es crucial recordar que umask nunca a\u00f1ade permisos; s\u00f3lo los resta<\/strong>. Para a\u00f1adir o cambiar permisos de algo que ya existe, usar\u00e1s chmod<\/code>, ACLs u otros mecanismos.<\/p>\n\n\n\n\nMicro-nota pr\u00e1ctica que me funciona: decide la umask por contexto<\/strong> (escritorio, carpeta de proyecto, servicio systemd) y documenta el porqu\u00e9. La \u201cumask por defecto\u201d rara vez sirve para todo.<\/p>\n<\/blockquote>\n\n\n\nC\u00f3mo se calculan los permisos: de 666\/777 a R = D & (~M)<\/code><\/h3>\n\n\n\nLa f\u00f3rmula mental r\u00e1pida:<\/p>\n\n\n\n
\nD<\/code> = permisos base solicitados (666 para archivos, 777 para directorios).<\/li>\n\n\n\nM<\/code> = umask (la m\u00e1scara).<\/li>\n\n\n\nR<\/code> = permisos resultantes = D & (~M)<\/code> (operaci\u00f3n bit a bit).<\/li>\n<\/ul>\n\n\n\nEjemplos t\u00edpicos:<\/p>\n\n\n\numask<\/th> Archivos nuevos<\/th> Directorios nuevos<\/th> Comentario<\/th><\/tr><\/thead> 000<\/td> 666 (-rw-rw-rw-)<\/td> 777 (drwxrwxrwx)<\/td> Todo abierto (raro y riesgoso).<\/td><\/tr> 002<\/strong><\/td>664 (-rw-rw-r–)<\/strong><\/td>775 (drwxrwxr-x)<\/strong><\/td>Colaboraci\u00f3n en grupo sin fricciones.<\/td><\/tr> 007<\/td> 660 (-rw-rw—-)<\/td> 770 (drwxrwx—)<\/td> Grupo cerrado; nadie fuera del grupo entra.<\/td><\/tr> 022<\/strong><\/td>644 (-rw-r–r–)<\/strong><\/td>755 (drwxr-xr-x)<\/strong><\/td>Cl\u00e1sico en estaciones individuales.<\/td><\/tr> 027<\/strong><\/td>640 (-rw-r—–)<\/strong><\/td>750 (drwxr-x—)<\/strong><\/td>Buen equilibrio seguridad\/colaboraci\u00f3n.<\/td><\/tr> 077<\/strong><\/td>600 (-rw——-)<\/strong><\/td>700 (drwx——)<\/strong><\/td>M\u00e1xima privacidad (\u00fatil para servicios).<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n\nA m\u00ed me ha salvado m\u00e1s de una vez tener 002<\/strong> en carpetas de proyecto compartido: todos pueden leer\/escribir, y otros usuarios del sistema no estorban.<\/p>\n<\/blockquote>\n\n\n\nOctal vs simb\u00f3lico: usando umask<\/code> y umask -S<\/code><\/h3>\n\n\n\n\n- Octal<\/strong>:
umask 022<\/code>, umask 027<\/code>, etc. Es la forma m\u00e1s com\u00fan.<\/li>\n\n\n\n- Ver en simb\u00f3lico<\/strong> (legible tipo
chmod<\/code>): umask -S<\/code> (por ejemplo, para 022 suele mostrarse u=rwx,g=rx,o=rx<\/code>).<\/li>\n\n\n\n- Imprimible<\/strong> (para scripts):
umask -p<\/code> devuelve una l\u00ednea reutilizable como umask 022<\/code>.<\/li>\n<\/ul>\n\n\n\n
\n\n\n\nVer y cambiar tu umask<\/h2>\n\n\n\nCambio temporal (s\u00f3lo esta sesi\u00f3n\/shell)<\/h3>\n\n\n\n# Ver el valor actual en octal y en simb\u00f3lico\numask\numask -S\n\n# Cambiar s\u00f3lo para esta shell (y subshells)\numask 002\n<\/code><\/pre>\n\n\n\nEste ajuste se pierde cuando cierras la sesi\u00f3n o el proceso que lo estableci\u00f3. En scripts, la umask del proceso padre<\/strong> puede afectar el resultado si t\u00fa no fijas una expl\u00edcita al inicio.<\/p>\n\n\n\n\nConsejo que me ha evitado sustos: al principio de los scripts que crean archivos, deja claro tu umask<\/code><\/strong>. Ej.: umask 077<\/code> para credenciales.<\/p>\n<\/blockquote>\n\n\n\nConfiguraci\u00f3n permanente por usuario (~\/.bashrc<\/code>, perfiles)<\/h3>\n\n\n\nPara Bash interactivo, a\u00f1ade a ~\/.bashrc<\/code>:<\/p>\n\n\n\n# ~\/.bashrc\numask 022\n<\/code><\/pre>\n\n\n\nPara shells de login<\/strong> (primera sesi\u00f3n textual o SSH), tambi\u00e9n puedes ponerlo en ~\/.profile<\/code> o ~\/.bash_profile<\/code> seg\u00fan distro\/shell. En Zsh, ~\/.zshrc<\/code>. Tras editar, abre una nueva sesi\u00f3n o recarga: . ~\/.bashrc<\/code>.<\/p>\n\n\n\nNota<\/strong>: si tu distro usa \u201cuser private groups\u201d, a veces es razonable 002<\/strong> para trabajo colaborativo dentro del mismo grupo del usuario.<\/p>\n\n\n\nConfiguraci\u00f3n a nivel de sistema (\/etc\/profile<\/code>, PAM y servicios)<\/h3>\n\n\n\n\n- Global interactivo<\/strong>:
\/etc\/profile<\/code> (y en algunas distros \/etc\/bash.bashrc<\/code>). \u00dasalo con criterio: afectar\u00e1 a todos<\/em> los usuarios interactivos.<\/li>\n\n\n\n- PAM (inicio de sesi\u00f3n)<\/strong>: el m\u00f3dulo
pam_umask<\/code> permite definir\/forzar umasks en el login (archivos en \/etc\/pam.d\/<\/code>). \u00datil en entornos multiusuario o con pol\u00edticas centralizadas.<\/li>\n\n\n\n- Servicios systemd<\/strong>: cada servicio puede tener su propia umask:<\/li>\n<\/ul>\n\n\n\n
# \/etc\/systemd\/system\/mi-servicio.service\n[Service]\nUMask=007\n<\/code><\/pre>\n\n\n\nLuego: sudo systemctl daemon-reload && sudo systemctl restart mi-servicio<\/code>.<\/p>\n\n\n\n\nEn mi d\u00eda a d\u00eda, separar umask de usuarios<\/strong> (p. ej., 022\/002) de la umask de servicios<\/strong> (a menudo 077) me ha dado tranquilidad: los binarios escriben con lo m\u00ednimo necesario.<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\nValores recomendados seg\u00fan escenario<\/h2>\n\n\n\nEscritorio individual (comodidad vs privacidad)<\/h3>\n\n\n\n
Si trabajas en tu propia cuenta y rara vez compartes archivos con otros usuarios del mismo host, 022<\/strong> suele ser c\u00f3modo: los nuevos archivos salen como 644 y las carpetas 755. Nadie ajeno puede escribir en tus cosas, pero s\u00ed leer si tiene acceso al path. Si te preocupa la lectura por terceros locales (logs con datos sensibles, por ejemplo), podr\u00edas optar por 027<\/strong> (archivos 640, carpetas 750) y a\u00f1adir al grupo s\u00f3lo a quien deba leer.<\/p>\n\n\n\nInserci\u00f3n personal: \u201cLos permisos que nacen con el archivo importan tanto como los que ajustas despu\u00e9s.\u201d<\/strong> En mi caso, cuando s\u00e9 que voy a generar reportes con datos internos, bajo a 027<\/strong> y me olvido de tener que \u201cchmodear\u201d luego.<\/p>\n\n\n\nColaboraci\u00f3n en grupo (002<\/code>) sin romper el flujo<\/h3>\n\n\n\nPara directorios compartidos entre usuarios del mismo grupo<\/em>, 002<\/strong> es oro: archivos 664 y carpetas 775. As\u00ed, quien comparta el grupo puede editar lo reci\u00e9n creado sin molestarte para que cambies permisos. Complementa con:<\/p>\n\n\n\n# Carpeta de proyecto compartida\nsudo chgrp -R mi-grupo \/ruta\/proyecto\nsudo chmod -R 2775 \/ruta\/proyecto # bit setgid en directorios para heredar grupo\numask 002 # en sesiones que trabajen ah\u00ed\n<\/code><\/pre>\n\n\n\nEl bit setgid (2xxx)<\/strong> en directorios hace que todo lo nuevo herede el grupo<\/strong> del directorio, manteniendo la colaboraci\u00f3n fluida.<\/p>\n\n\n\n\nEn entornos compartidos, me he encontrado con fricci\u00f3n constante cuando la umask era 022: el autor pod\u00eda editar, su grupo no. Con 002<\/strong> esa fricci\u00f3n desaparece.<\/p>\n<\/blockquote>\n\n\n\nM\u00e1xima seguridad (027<\/code>\/077<\/code>) y servicios (ej. web)<\/h3>\n\n\n\nEn servidores y procesos que manipulan credenciales o datos sensibles, 077<\/strong> es una postura fuerte: archivos 600 y carpetas 700; nadie fuera del usuario del proceso puede leer o escribir. Para servicios que necesitan que el grupo lea (pero no el resto), 027<\/strong> equilibra bien.<\/p>\n\n\n\nPara servicios systemd<\/strong>, define UMask=077<\/code> en la unidad y rev\u00edsalo en logs<\/strong> si el servicio espera permisos m\u00e1s abiertos. A veces aplicaciones web crean directorios de subida o cach\u00e9 y fracasan si no pueden ser le\u00eddos por el proceso HTTP: ajusta grupo\/propiedad y, si es imprescindible, rebaja a 027<\/strong> en ese servicio concreto.<\/p>\n\n\n\n\n\u201cSi varios usuarios colaboran, una umask demasiado restrictiva o demasiado laxa rompe el flujo.\u201d En servicios, prefiero pecar de restrictivo<\/strong> y abrir s\u00f3lo lo necesario.<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\nErrores comunes con umask y c\u00f3mo evitarlos<\/h2>\n\n\n\nSubshells, scripts y herencia de entorno<\/h3>\n\n\n\n
Cada proceso tiene su umask<\/code>. Si un script ejecuta otro (subshell), hereda el valor a menos que lo cambies<\/strong>. Por eso:<\/p>\n\n\n\n\n- Declara tu
umask<\/code> al inicio de scripts que creen archivos: umask 077<\/code>.<\/li>\n\n\n\n- En cron\/systemd, la umask por defecto puede ser distinta<\/strong> a tu shell interactiva. Decl\u00e1rala expl\u00edcitamente.<\/li>\n\n\n\n
- En sesiones SSH, el stack de PAM<\/strong> puede aplicar
pam_umask<\/code> y sorprenderte. Comprueba con umask<\/code> nada m\u00e1s entrar.<\/li>\n<\/ul>\n\n\n\nDiferencias con chmod<\/code> y con ACLs<\/h3>\n\n\n\n\numask<\/code><\/strong>: s\u00f3lo afecta a lo que a\u00fan no existe<\/strong>. No puede a\u00f1adir<\/strong> permisos; s\u00f3lo los quita<\/strong> del valor base.<\/li>\n\n\n\nchmod<\/code><\/strong>: modifica permisos de objetos existentes<\/strong> (puede a\u00f1adir o quitar).<\/li>\n\n\n\n- ACLs (Access Control Lists)<\/strong>: permiten reglas m\u00e1s finas. Los ACLs por defecto en un directorio<\/strong> pueden afinar o incluso redefinir<\/strong> lo que esperas de la umask para objetos creados dentro. Si tu carpeta tiene ACLs por defecto, revisa
getfacl<\/code><\/strong>; quiz\u00e1 la umask no explique por s\u00ed sola el resultado.<\/li>\n<\/ul>\n\n\n\nChecklist r\u00e1pido cuando \u201cno cuadran\u201d los permisos reci\u00e9n creados:<\/p>\n\n\n\n
\n- \u00bfQu\u00e9
umask<\/code> tiene el proceso que crea? (strace -e umask<\/code> o imprime umask<\/code> al inicio del script).<\/li>\n\n\n\n- \u00bfHay ACL por defecto en el directorio padre? (
getfacl .<\/code>).<\/li>\n\n\n\n- \u00bfEl servicio tiene
UMask=<\/code> propia en systemd?<\/li>\n\n\n\n- \u00bfEl directorio usa setgid<\/strong> para heredar grupo? (
ls -ld<\/code> y busca s<\/code> en el grupo).<\/li>\n<\/ol>\n\n\n\n\nPeque\u00f1a lecci\u00f3n que aprend\u00ed a golpes: cuando diagnostiques \u201cpor qu\u00e9 este archivo naci\u00f3 con 640 y no 664\u201d, mira el directorio padre<\/strong> y el proceso que lo cre\u00f3, no s\u00f3lo tu shell.<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\nFAQs r\u00e1pidas sobre umask<\/h2>\n\n\n\n
\u00bfPuedo hacer que los archivos nazcan con permiso de ejecuci\u00f3n?<\/strong>
No por umask: la herramienta que crea el archivo debe solicitar x<\/code>. Umask s\u00f3lo quita, no a\u00f1ade.<\/p>\n\n\n\n\u00bfUmask 002 es inseguro?<\/strong>
Depende. En un host multiusuario y sin aislamiento, dar escritura al grupo puede ser indeseable. En un equipo donde todos pertenecen al mismo grupo de proyecto, 002 es pr\u00e1ctico<\/strong>.<\/p>\n\n\n\n\u00bfD\u00f3nde pongo la umask para SSH?<\/strong>
Puedes fijarla en ~\/.bashrc<\/code>\/~\/.profile<\/code>. Si tu organizaci\u00f3n usa PAM, se puede imponer v\u00eda pam_umask<\/code> (pregunta a quien administre el stack PAM).<\/p>\n\n\n\n\u00bfPor qu\u00e9 umask -S<\/code> me muestra u=rwx,g=rx,o=rx<\/code> con umask 022?<\/strong>
Es la representaci\u00f3n simb\u00f3lica equivalente; lo importante es que 022 \u2192 archivos 644 \/ directorios 755<\/strong>.<\/p>\n\n\n\n\u00bfCambia algo con contenedores\/Docker?<\/strong>
S\u00ed: cada contenedor\/proceso tiene su propia umask. Decl\u00e1rala en la entrypoint<\/strong> o en el propio servicio que corre dentro, y controla permisos de vol\u00famenes compartidos.<\/p>\n\n\n\n
\n\n\n\nSobre Umask<\/h2>\n\n\n\n
umask<\/code> es una palanca peque\u00f1a con impacto grande. Si trabajas en entornos compartidos, decidir la umask por contexto<\/strong> evita sorpresas: 002<\/strong> para colaborar sin fricci\u00f3n, 022<\/strong> para estaciones individuales, 027\/077<\/strong> cuando la privacidad manda, y UMask=<\/code> espec\u00edfico en servicios. Al final, los permisos con los que \u201cnacen\u201d tus archivos<\/strong> pueden ahorrarte (o generarte) mucho trabajo.<\/p>\n\n\n\nOpini\u00f3n Personal<\/strong><\/p>\n\n\n\nSi algo he aprendido en Linux es que umask no es un detalle t\u00e9cnico<\/strong>, es pol\u00edtica operativa<\/em>. Define c\u00f3mo \u201cnacen\u201d tus archivos y, con ello, tu modelo de confianza. En entornos compartidos, defender\u00e9 siempre 002<\/strong> para no frenar a tu equipo; nada mata m\u00e1s la colaboraci\u00f3n que un archivo reci\u00e9n creado que el resto no puede editar. En servidores y procesos con datos sensibles, mi postura es clara: 077<\/strong> o, como m\u00ednimo, 027<\/strong>. Prefiero pecar de restrictivo en servicios<\/strong> y abrir s\u00f3lo lo imprescindible, que al rev\u00e9s.<\/p>\n\n\n\n