Un script qui crée des fichiers avec les permissions attendues quand il est lancé à la main, mais avec des permissions différentes une fois exécuté par cron, pointe presque toujours vers un umask différent entre les deux contextes, rarement vers un bug du script lui-même.

Ce que umask fait réellement

umask définit un masque de bits soustrait des permissions par défaut à la création d’un fichier ou d’un répertoire, jamais appliqué après coup à un fichier existant. Un fichier créé sans permission d’exécution part d’une base 666 (lecture/écriture pour tous), un répertoire part d’une base 777 (l’exécution sur un répertoire signifie « autorisé à y entrer »), et umask retire les bits correspondants de cette base.

# umask 022 : retire l'écriture pour le groupe et les autres
umask
# 0022

# Fichier créé : 666 - 022 = 644 (rw-r--r--)
touch fichier.txt && ls -l fichier.txt

# Répertoire créé : 777 - 022 = 755 (rwxr-xr-x)
mkdir dossier && ls -ld dossier

Le piège : fichiers et répertoires ne réagissent pas pareil

Le même umask produit un résultat différent selon qu’on crée un fichier ou un répertoire, une source de confusion fréquente pour qui raisonne uniquement en pourcentage soustrait plutôt qu’en bits retirés depuis la base réelle (666 contre 777). Un umask 022 retire l’écriture groupe/autres dans les deux cas, mais le bit d’exécution ne disparaît que là où il n’était pas prévu au départ, c’est-à-dire jamais sur un fichier normal créé par une redirection shell ou un touch.

Pourquoi cron hérite rarement du umask du shell

Un shell interactif hérite généralement de l’umask configuré dans /etc/profile ou le fichier de démarrage de l’utilisateur (022 étant une valeur courante). cron, en revanche, exécute les tâches dans un environnement minimal qui ne source pas ces fichiers de démarrage : sans directive umask explicite dans le crontab lui-même, la valeur effective peut différer de celle du shell interactif, produisant des fichiers plus ou moins permissifs que ce à quoi le script s’attendait en étant testé à la main.

# Umask explicite dans le crontab,
# indépendant de tout fichier de démarrage shell
UMASK=022
0 3 * * * /usr/local/bin/backup.sh

À retenir

umask soustrait des bits d’une base 666 (fichiers) ou 777 (répertoires) au moment de la création, jamais après coup, une distinction qui explique pourquoi le même masque produit des résultats visuellement différents entre un fichier et un répertoire. cron n’hérite pas automatiquement de l’umask configuré pour un shell interactif, faute de sourcer les mêmes fichiers de démarrage : un script aux permissions correctes en test manuel mais incohérentes une fois planifié pointe vers cet écart, une directive UMASK explicite dans le crontab réglant le problème à la racine plutôt qu’en corrigeant les permissions après coup.