Developer tools · Chmod calculator
How umask decides the default permissions of new files and folders
· How it works
chmod unix developer-workflow
New files do not start at 777; a mask is applied first. This post shows the exact bitwise operation, why files and directories end up different, and how to reason about umask 022, 027 and 077.
Files the web server cannot read — a cron job writes 600 files into a directory nginx serves, and nobody ran chmod on anything
A newly observed file mode can be decoded here even when the process that produced it is unknown. Enter 600 and the calculator shows rw-------: owner read and write, with no permissions for group or other. That explains the supplied result's bits. It does not establish why a scheduled job produced that value or whether a web process can read the file.
Article 501 supplies the necessary diagnostic restraint. A valid mode may coexist with wrong ownership or a missing execute bit on a parent directory. This page receives neither process identity nor path information. It can compare 600 with a proposed 640 and expose the added group-read bit, but it cannot attribute the original mode to umask, a service, a shell, or a filesystem.
Where new permissions come from — the requested mode (usually 666 for files, 777 for directories) and the process's umask
Requested creation modes and umask are background inputs, not calculator controls. There is no umask field and no operation that creates a file or directory. Any creation-mode example must therefore arrive as an externally computed result. Once supplied, the calculator can translate that result among octal, symbolic, matrix, summary, and plain-English forms without claiming how the value was obtained.
This corrected scope matters because synchronized output can look more authoritative than it is. Entering 640 yields rw-r----- and identifies owner read/write plus group read. The page can verify that representation. It cannot predict defaults for a login process, scheduled task, service, container, or storage system, because none of those contexts appears among its inputs or implementation.
Requested creation modes and umask are background inputs not implemented here
AND-NOT arithmetic must be performed outside this calculator. Its core accepts one completed integer and explodes it into named flags; it has no second operand for a creation mask. Consequently, the page cannot demonstrate a mask formula, compare subtraction with bitwise operations, or decide whether an external computation was performed correctly before its resulting mode was entered.
What it can check is the final bit pattern. If another trusted source supplies 640, the matrix shows owner read and write, group read, and no other permissions. Changing group read off rebuilds 600, while changing other read on rebuilds 644. These transitions verify mode arithmetic inside the converter without presenting them as creation-mask calculations or evidence about an unseen process.
AND-NOT arithmetic must be performed outside the calculator
The calculator can compare resulting file and directory modes, but it creates neither. With 644 selected, the regular-file explanation describes reading and changing a file; switching the target to directory changes those verbs to listing, modifying entries, and reaching names. The integer remains 644. That contrast demonstrates why target type matters without asserting which creation defaults any program requests.
A separately supplied 755 result can be inspected the same way. Its display is rwxr-xr-x, with execute active for all classes; 644 is rw-r--r--, with execute absent throughout. The page clearly exposes that difference. It does not derive either value from 666, 777, 022, or any other background input, because those calculations are not implemented in CHMOD_SOURCES.
The calculator can compare resulting file and directory modes but creates neither
For a restrictive-mask example, keep the computation external and decode only the stated results. If an observed regular file is 640, the calculator renders rw-r-----; if an observed directory is 750, it renders rwxr-x---. The owner retains broader access in both, group receives a narrower set, and other receives none. Those statements follow directly from the completed modes.
Another externally supplied pair, 600 and 700, makes the same review method visible without claiming its origin. Mode 600 gives only owner read and write on a file. Mode 700 gives only owner read, write, and execute on a directory. The converter can confirm each class and bit, but it cannot match either result to a particular umask setting from its own evidence.
Worked example: decode externally computed results for restrictive masks
Where a process obtains umask is outside repository evidence. The calculator contains no integration with shells, schedulers, service managers, containers, or process environments. Naming one of those systems as the cause of a mode would therefore exceed what the page observes. Begin with a trustworthy mode gathered elsewhere, then use this route only to make its owner, group, and other bits legible.
The command preview does not close that evidence gap. It can quote a supplied path and optionally display -R, but it never opens the path or reads process settings. Likewise, the target selector changes explanatory language rather than discovering an object type. A consistent conversion narrows the permissions question; it does not reveal which component selected the mode or whether the selection was intentional.
Where a process obtains umask is outside repository evidence
Default ACLs and explicit creation modes are outside this tool. Its data model has one owner class, one group class, everyone else, and three special bits. There are no named ACL entries, ACL masks, creation calls, or program arguments. The calculator therefore cannot decide whether a completed mode arose from another access-control layer or from an application supplying a particular request.
A mode can still be checked without collapsing those mechanisms together. Enter the observed octal value, confirm the nine symbolic positions, and compare the matrix with the four-digit summary. If they agree, the traditional mode has been decoded correctly. Any claim about defaults, ACL effects, or program behavior requires evidence from the creator and filesystem, not another interpretation of the same integer.
Default ACLs and explicit open modes are outside this tool
The corrected workflow is compute elsewhere, then inspect the resulting mode here. Supply the completed octal or ls-style string and let the synchronized fields expose each bit. Validation catches malformed octal digits and letters in incorrect symbolic positions. It does not validate a umask expression, discover a creation context, or predict what a future file or directory will receive.
Treat the result as one diagnostic layer. A decoded 640 or 750 can reveal an unexpected grant or missing execute bit, while article 501 reminds us to check ownership and parent-directory traversal separately. Stop before assigning a cause. The calculator proves how a supplied value maps to permissions; it offers no basis for claims about shell, service, container, ACL, or filesystem defaults.