Quand je me connecte à nouveau, mon umask est 002
. Au moins pour un moment. Puis, à un moment donné, et je ne sais pas quand, cela revient à 000
. Ceci est très gênant et je crains maintenant de perdre des fichiers et des dossiers avec des autorisations étranges dans mon répertoire personnel.
Le retour à 000
peut se produire après quelques minutes d'utilisation ou plusieurs jours. Quelques semaines après ma première installation d'ubuntu, il s'est passé beaucoup de choses, puis il s'est refroidi et, ces derniers jours, le problème a de nouveau pris de l'ampleur.
Je peux le redéfinir sur 002
avec $ umask 002
, mais cela ne fonctionne que pour le shell actuel (comme prévu).
Quelques informations supplémentaires:
002
même lorsque ma connexion f7 est à 000
/etc/profile
indique que umask est maintenant géré par pam_umask/etc/login.defs
a UMASK 022
et USERGROUPS_ENAB yes
J'utilise Ubuntu 13.10 avec XMonad et (oh-my-) zsh.
Au cas où cela serait utile, voici mon /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sdb8 during installation
UUID=96f989e0-ee94-4bff-9663-3fa479a83ad4 / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sdb1 during installation
UUID=7682-B8AD /boot/efi vfat defaults 0 1
# swap was on /dev/sdb7 during installation
UUID=0d7d57af-9a31-481e-9da4-1032c94f57e9 none swap sw 0 0
Voici une version abrégée de ma crontab de crontab -l
* * * * * cd /home/miles/code/Checkin/ && ./node_modules/.bin/coffee ./client.coffee -n attercop -h secret1.com -p 8888
* * * * * cd /home/miles/code/Checkin/ && ./node_modules/.bin/coffee ./client.coffee -n attercop -h secret2.com -p 8888
client.coffee
est juste un script qui envoie une requête http.
Et ma crontab racine de Sudo crontab -l
rapporte no crontab for root
Le problème pour moi a été causé par un plugin Sublime Text 3 appelé Terminal, utilisé pour lancer des terminaux à partir de fichiers sublimes. Lorsque Terminal a lancé la fenêtre première et unique de gnome-terminal, il a hérité du umask de 000
de sublime.
Dans l'espoir que cette réponse puisse être utile à ceux qui ne rencontrent pas le même problème que moi, je réitérerai quelques suggestions sur la façon de s'attaquer à ce problème, tirées des commentaires ci-dessus:
.bashrc
, .zshrc
) pour voir s’il existe des appels errants umask
.bash -x -l -i -c 'exit' 2>&1 | grep umask
pour trouver l'appel à umask à partir de vos fichiers rc.zsh -x -l -i -c 'exit' 2>&1 | grep umask
pour rechercher les appels à umask
à partir de vos fichiers rc.$HOME
. Regardez dans /etc/fstab
crontab -l
et Sudo crontab -l
.audit
pour trouver la source de mystérieux changements d'umask. Sudo auditctl -A auditctl exit,always -S umask
et regardez dans /var/log/kern.log