Linux Permission Denied: Diagnose the User, Path, and Mode

The file has read permission, but cat still says Permission denied. Changing the file to mode 777 would not explain the failure: the process may be unable to traverse one of the directories leading to it.

Identify the user performing the operation, the operation itself, and every component of the path before changing permissions. Reading a file, creating a file, executing a program, and listing a directory need different access.

The example below deliberately removes directory search permission in a new practice folder. Run it as a normal user in a Linux shell, without sudo. It does not require changing a system directory or creating another account.

Record the failing operation

Keep the exact error and the command that produced it. Start with:

id
pwd

id describes the current shell’s identity and groups. That is relevant if the shell is running the failing command directly. A web service, scheduled job, or container process may use another identity, so your successful cat does not prove that the service can read the same file.

Also preserve the path spelling. A relative path starts from the process’s working directory. A familiar filename in a different directory is a different object.

Use the operation to decide what to inspect:

Operation	Ordinary permission checks to investigate
Read an existing file	Search access through its parent directories and read access on the file
Write an existing file	Parent traversal and write access on the file
Create a new file	Search and write access on the containing directory
List directory entry names	Read access on the directory; inspecting those entries also needs search access
Execute a file directly	Parent traversal and executable-file requirements, plus mount and interpreter constraints

These are the ordinary mode-bit checks, not a complete list of Linux access controls. ACLs, security policies, capabilities, and mount options can change the diagnosis.

Read the relevant class of bits

A regular file with mode -rw-r----- gives its owner read/write access, its group read access, and others no access. Under ordinary mode checks, the owner uses the owner class; membership does not let that owner fall through to a more permissive group or other class.

The Linux path-resolution manual describes how credentials select permission classes. The GNU mode reference explains their file and directory meanings.

For a directory, x means search: the ability to traverse it while resolving a pathname. It is not a request to execute the directory as a program. This is why changing only the final file can miss the actual barrier.

Reproduce a readable file behind an inaccessible directory

Create a dedicated workspace and give yourself explicit initial permissions:

mkdir permission-demo
cd permission-demo
mkdir private
printf 'service configuration\n' > private/config.txt
chmod 700 private
chmod 600 private/config.txt
cat private/config.txt

The read should succeed. Now remove only the owner’s search bit from the directory:

chmod u-x private
ls -ld private
cat private/config.txt

The directory mode should show drw-------, and the read should fail with a permission error. The file’s own read bit has not changed. You have prevented path traversal before the file can be opened.

On a Linux system with util-linux installed, inspect the path component by component:

namei -l "$PWD/private/config.txt"

The namei manual documents -l for modes and ownership. Look for the private directory without search permission. The tool may be unable to inspect the final file beyond that barrier; that inability is itself useful evidence. If namei is unavailable, inspect known parent directories with ls -ld instead of assuming the last file is at fault.

Restore precisely the bit you removed:

chmod u+x private
cat private/config.txt

The original read should work again. You have repaired a demonstrated cause without granting write or execute permission to everyone.

If the failure did not occur, first check whether you ran as root or with privileges that bypass ordinary discretionary access checks. Also confirm that you used a normal local Linux filesystem rather than a mount with different permission semantics. Do not change more permissions just to force a demonstration to match.

Execution is a different operation from reading

A script can be readable without being directly executable. From the same practice directory:

printf '#!/bin/sh\nprintf "script ran\\n"\n' > hello.sh
chmod 600 hello.sh
./hello.sh

Direct execution should fail under ordinary file modes. Compare:

sh hello.sh

Here the shell executable runs and reads hello.sh as input. You did not make the script executable; you used a different operation. To allow direct execution for the owner:

chmod u+x hello.sh
./hello.sh

This distinction helps diagnose scripts launched by another program. Check how that program invokes the script, not only whether you can run it through an interpreter yourself. Direct execution can also fail because of a noexec mount or interpreter-path problem; the presence of an x bit does not settle every case.

Why sudo before echo can still fail

Consider this pattern with a root-owned configuration file:

sudo echo value > /path/to/root-owned-file

The invoking shell handles > before the elevated command writes its output. If that shell cannot open the target, elevating echo does not fix the redirection. The Bash redirection reference describes the shell’s role in opening files.

When you actually intend and are authorized to write a privileged file, a program that performs the write can run with the required privilege, for example printf ... | sudo tee .... That is an explanation of the boundary, not a command to paste into an unknown system file. Check whether the intended operation is replacement or append, and inspect the target before changing it.

For the local exercise, no elevation is needed. Using sudo would bypass the very identity check you are trying to understand.

If ordinary modes do not explain it

Return to the actual failing identity and path before widening access. Ask the next question supported by the evidence:

• Is there an ACL? On systems with ACL tools, getfacl /actual/path can show access entries and masks beyond the basic mode display.
• Does the failure occur only under a service? Inspect the configured service user, supplementary groups, working directory, and any filesystem restrictions.
• Is it a mount issue? A read-only filesystem usually reports a different error from an ordinary permission denial; inspect the exact message and mount options.
• Is a security policy involved? Inspect the relevant SELinux or AppArmor audit information for that system rather than disabling the policy to see what happens.

A recursive chmod -R 777 erases useful distinctions across directories, data files, and executables. It also grants unrelated users access. A narrow repair should name the identity, object, and operation it enables, then repeat the original failing command under the same conditions.

For structured follow-up, LabEx Users, Groups, and Permissions lists activities on ownership, mode bits, symbolic and octal changes, and umask. Use them to practice explaining the resulting access, not simply obtaining a successful command exit.

Clean up the demonstrated files

After restoring directory search permission, run this from permission-demo:

rm private/config.txt hello.sh
rmdir private
cd ..
rmdir permission-demo

If you added other files, rmdir will refuse to remove the nonempty directory. For your next real permission error, write down three things before any repair: the acting identity, the exact operation, and the first path component whose access you cannot explain.

References

• Linux path resolution — path traversal and credential-based permission checks.
• GNU mode structure — owner/group/other bits and directory meanings.
• namei — inspect a pathname’s components.
• Bash redirections — which process opens a redirected file.
• LabEx Users, Groups, and Permissions — related guided practice.