How this calculation works
Each owner, group and other octal digit represents three independent binary flags. Special bits occupy an additional digit. Calculate new-object creation separately: a umask removes requested flags with a bitwise operation; it does not subtract a decimal number from a chmod command.
Octal class digit = 4×read + 2×write + execute; created ordinary bits = requested AND NOT umaskA worked example
Mode 755 displays rwxr-xr-x: owner has 4+2+1, while group and other each have 4+1. For a separate request of 666 with umask 022, the created ordinary bits are 644.
Good to know
A permission-bit model, not a command runner or effective-access audit. ACLs, inherited directory rules, filesystem policy and platform-specific special-bit behavior are excluded. Uppercase S/T indicates a special bit without the corresponding execute bit. No file is read or changed.
Reference: GNU Coreutils: numeric permission modes (opens in a new tab) ↗
Each octal digit represents three binary flags
Read, write and execute/search carry weights 4, 2 and 1 within each ordinary permission class. Add the enabled weights to get one octal digit. Owner, group and other each receive their own digit.
For 755, the owner’s seven is 4+2+1, while each five is 4+1. The symbolic display is rwxr-xr-x. The decimal bitmask is a different representation of the same flags; it is not a decimal permission command.
The number base converter changes integer representations; this chmod permission calculator also explains the mode flags and separate creation mask.
Special bits explain uppercase letters
A leading special digit describes set-user-ID, set-group-ID and sticky bits. In symbolic output, s or t replaces a corresponding enabled execute position; uppercase S or T shows a special bit where that execute flag is absent.
For example, 4755 displays rwsr-xr-x, while 4644 displays rwSr--r--. This describes the mode flags only. Whether a platform honors or preserves them in a specific context requires its filesystem and command documentation.
Umask is a separate creation operation
A requested new-object mode is filtered with requested bits AND NOT umask. A file request of 666 and mask 022 yields 644. It is not ordinary decimal subtraction and cannot enable an execute bit that was absent from the request.
The explicit mode field is displayed without applying the creation mask to it. This avoids suggesting that umask rewrites an explicit chmod setting. ACLs and inherited directory behavior remain outside the simple bit arithmetic. The number base converter can check octal against decimal; it cannot decide effective filesystem access.
A few questions, answered
Does this run chmod on my computer?
No. It calculates and displays flag representations only; it reads and changes no files.
Does 777 guarantee access?
No. Effective access can also depend on identity, ACLs, parent directories, filesystem policies and platform behavior.
Why is umask 022 with requested 666 equal to 644?
The mask removes the requested group-write and other-write flags. Other bits are kept. This is bitwise removal, not subtraction of decimal numbers.