I was cleaning up groups and permissions on my home system today, and re-familiarized myself with umasks. It seems that the default on my system (Ubuntu 18.10) is 002, but that for root it's 0022.

Ignoring the extra bit for the current purposes, this got me thinking. With a default of 002, any user in the group associated with my username will be able to edit my files. With 022, they won't. Now, I've never made use of this group before (nor root's group for that matter), so I have no idea why one would ever use it, nor which permissions would be appropriate in such a case.

In principle, why would you choose one of these options over the other? For bonus points, why would (this part of) the umask for root be different from ordinary users?

  • "It seems that the default on my system (Ubuntu 18.10) is 002" Is it really the default on Ubuntu, instead of 022?
    – user313992
    Commented Jun 13, 2019 at 20:14
  • Yep. To be sure, I created a new user and logged in. It came up as 0002, which I also get if I open bash as myself (normally I use zsh). Commented Jun 13, 2019 at 20:36
  • 1
    If you look at /etc/login.defs, it looks like the variable "USERGROUPS_ENAB", which is active on Ubuntu, causes this. I found an interesting answer that might explain why this is so, and how it might differ from other distros. Commented Jun 13, 2019 at 20:49
  • That option is also ON in Debian, but the created users will still have a 022 umask upon login. In order for them to have a 002 umask I had to also set UMASK 002 explicitly in that file and enable the pam_umask module with no arguments (which is not used by default). Tested with a vanilla system. The comment from that file about the USERGROUPS_ENAB option magically changing the umask from 022 to 002 seems completely bogus -- but maybe I'm too dense today and I'm misinterpreting it.
    – user313992
    Commented Jun 13, 2019 at 22:24
  • On macOS umask is 022. Commented Jun 9, 2021 at 20:37

1 Answer 1


With a default of 002, any user in the group associated with my username will be able to edit my files.

The idea isn't that there would be other users in the user's personal group. The idea is that there might be groups for projects or such, and they might have multiple users as members. The group owner of the files can then be the project (not any of the users personally), enforced by setgid on the project directory. With the umask allowing for write access to the group, such files would be writable by all members of the project group.

It works something like this, assuming foo is a user using umask 002:

# [add user foo to group proj]
# mkdir /work/proj
# chmod u=rwx,g=rwx,o=,g+s /work/proj
# ls -ld /work/proj
drwxrws--- 2 root proj 4096 Jun 14 17:48 /work/proj/
$ umask
$ cd /work/proj
$ echo "some data here" > file.txt
$ ls -l file.txt
-rw-rw-r-- 1 foo proj 15 Jun 14 17:51 file.txt

Note how the file was created a) with the group owner proj (because of the setgid on the directory), and b) with write permission to the whole group (because of the umask). Instead of requiring the users to have a proper umask, the directory could be set up with a default ACL, which replaces the function of the umask if set.

There's more on per-user groups and the umask at least here and in Red Hat's manuals (That's the manual for RHEL 4, the newer ones seemed to be briefer on the matter.) Also related is this q: Why does every user have their own group?

Nothing here prevents the users from manually messing up the permissions. It can't be prevented since the file owner can always change the permissions as they see fit. Nowadays people also more often use network services for collaboration, and such gymnastics with the file and directory permissions aren't necessary.

  • Got it. To summarize, the umask will also affect files created to be owned by other groups. The stereotypical case would be a group for a collaborative work, and in this case a umask 002 makes sense. So how about the case of 022 for root? Commented Jun 13, 2019 at 20:41
  • @KennethHanson, that I don't know for sure. It might be just to be more strict on root or because that's the way it was before and root probably doesn't need the more lax umask since they're not going to be in any project groups.
    – ilkkachu
    Commented Jun 14, 2019 at 15:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .