Changing umask does not repair the permissions of files that already exist. It influences permission bits when a process creates a new object. If yesterday’s export remains readable after you enter umask 077, that does not mean the command failed: the existing export has not been recreated or explicitly changed.
This distinction matters when investigating server-generated reports. Before changing permissions recursively, establish which process creates the files, what permissions it requests, and whether you are examining new files or repeatedly opening old ones.
Understand the creation-time boundary
The Linux umask system-call documentation explains that the mask turns off permission bits from the mode requested by file-creation calls. It cannot add permission bits the application did not request. A normal data file created with requested mode 0666 and mask 022 commonly becomes 0644; a directory requested as 0777 commonly becomes 0755.
Do not describe this as ordinary decimal subtraction. The operation removes selected bits. With mask 077, those same requests commonly produce a 0600 file and a 0700 directory. The file does not become executable simply because its owner has full directory access.
There is also an important exception: a parent directory’s default ACL changes the creation calculation. The manual describes inheritance of that ACL rather than application of the ordinary umask calculation, while still removing bits absent from the requested mode. Treat simple numeric predictions as conditional on the directory’s ACL environment.
Run an isolated before-and-after experiment
Use Bash and GNU stat on Linux. This example creates only a temporary lab directory, changes the mask inside a subshell, and prints its location for later inspection. It deliberately leaves the files in place rather than automatically deleting anything.
(
umask 022
lab=$(mktemp -d) || exit 1
printf 'Lab directory: %s\n' "$lab"
printf 'before\n' > "$lab/before.txt"
umask 077
printf 'after\n' > "$lab/after.txt"
mkdir -- "$lab/new-directory" || exit 1
stat -c '%a %n' -- "$lab/before.txt" "$lab/after.txt" "$lab/new-directory"
)
On a filesystem without an inherited default ACL affecting this example, expect 644 for before.txt, 600 for after.txt and 700 for new-directory. The first file remains 644 after the mask changes. The temporary parent is itself private; this experiment is about permission bits on the three child objects, not evidence that other users can traverse the parent.
The parentheses matter: the mask change is confined to that subshell. Your interactive parent shell keeps its original setting. Record the printed directory if you want to examine the objects later, and remove only those known lab objects when finished.
Separate your terminal from the actual writer
Typing a new mask into an administrator’s terminal does not update an already-running application. A child inherits its parent’s mask, and executing a new program preserves that process setting. The relevant question is therefore what mask the writer had when it created the object, not what your support terminal prints now.
Start with a non-mutating umask in the shell you are investigating. For a known Linux process, its /proc/PID/status file can expose an Umask field on supported kernels, subject to access restrictions. Obtain the real writer’s PID rather than substituting a convenient terminal process. Inspect service configuration through your normal approved process before considering a restart or configuration edit.
Choose a targeted repair, not a recursive guess
If an existing file needs different permissions, that is a separate authorised change. Record ownership, current permission bits, intended readers, directory access and any ACLs first. An application may later recreate or explicitly change the file, so a one-off correction is not necessarily a durable fix.
If permissions appear sufficient but access still fails, investigate the path rather than broadening access. Our parent-directory permission inspection tutorial explains why a readable file can remain inaccessible. Avoid blanket recursive chmod commands that might expose unrelated reports or remove directory traversal permissions.
Quick questions before closing the incident
- Was the file newly created after the setting changed, or was an existing file reused?
- Did the actual writer inherit the intended mask?
- Does the parent directory have a default ACL?
- Did the application request restrictive permissions or change them after creation?
- Have you checked the intended user’s complete access path?
Does 077 secure old exports? No. Review old objects separately. Does the lab prove a production service is fixed? No. It demonstrates creation behaviour in a disposable location, not your application’s runtime configuration.
Educational disclaimer: This tutorial is for educational purposes. Test carefully before using steps in production. WhileNetworking is not responsible for misuse, damage, data loss or production issues.
