umask Calculator

The rule, in one sentence

Permission bit positions that are set in cmask are cleared in the mode of the created file.

POSIX.1-2024 (IEEE Std 1003.1-2024), XSH umask() — DESCRIPTION. The Open Group’s own free HTML edition, read directly.

Everything else follows from that. A umask is a set of bits to remove, applied to the mode the creating program requested — not to some notional default. The two requests that matter in practice are 0666, which is what tools ask for when creating an ordinary file, and 0777, which is what mkdir asks for. So:

file mode      = 0666 AND NOT umask
directory mode = 0777 AND NOT umask

The consequence people trip over: because the file base is 0666 and that has no execute bits, no umask value can produce an executable file. A umask of 000 gives you 666, not 777. If your build system is producing non-executable scripts, the umask is not the lever — the tool creating them is.

The values worth knowing

All 512 values

Eight blocks of 64, keyed on the first digit of the umask. Every value from 000 to 777 is present; none is skipped and none is summarised.

The file column repeats; the directory column does not

The two result columns behave differently, and the difference is worth a moment. There are 512 umask values and 512 distinct directory modes — one for each, a perfect one-to-one mapping, because the directory base 0777 contains every bit a umask could remove. But there are only 64 distinct file modes, because the file base 0666 has no execute bits, and a bit that is already absent cannot be removed again.

So every umask that differs only in its execute bits produces an identical file mode. umask 022 and umask 122 both give 644 files and differ only in the directory column, where the first yields 755 and the second 655.

That is a genuinely useful thing to notice when reading someone else's configuration. A umask with odd digits is doing something to directories and nothing to files, and is usually either deliberate and clever or copied and misunderstood.

Where to set it, and where that will not work

The mask is per-process and inherited by children, which makes "where do I set it" a question about process ancestry, not about configuration files. Three cases people get wrong:

• A line in ~/.bashrc applies to interactive shells. It does not apply to a cron job, a systemd service, or anything a daemon spawns, because none of those is a child of your login shell.
• A systemd service takes UMask= in its unit file. Setting it there is the only reliable way to control the modes that service creates; inheriting it from a shell profile will appear to work in testing and fail after a reboot.
• Files that already exist are unaffected by any umask change, ever. Changing the mask changes what gets created next. Existing files need a chmod pass — typically the two find commands on the 755 page.

For a shared group directory, the umask and the setgid bit solve different halves of the same problem: chmod 2775 makes new entries inherit the directory's group, and umask 002 keeps the group-write bit from being masked off as they are created. Set one without the other and the collaboration still fails — with the setgid bit alone the group is right and the mode is read-only; with the umask alone the mode is right and the group is whoever happened to create the file.

One last check that costs nothing: run umask with no arguments in the exact context you care about. In a cron job that means putting umask in the job itself and reading the mail it sends. The value you assume is inherited very often is not.