Payments are experiencing issues due to temporary restrictions in Russia. If your payment does not go through, please submit a support request.Our support team is available 24/7 — we are always here to help with hosting and server issues.We are now accepting requests for dedicated server rental and colocation services in our data center.Reminder: we recommend enabling backups for additional data protection.A new VPS/VDS lineup with NVMe storage and improved performance is now available.Maintenance work on some servers has been completed. All services are operating normally.
Article6 min readViews2

Permission denied: How to find a directory without search permission using namei

Practical diagnosis of Permission denied in Linux: decompose the path with namei -l, locate an intermediate directory lacking search permission x, and verify a targeted fix without recursive chmod.

МихаилCommunity author★ 14
Comments 0

Metal fence with a lock between server racks and diagnostic tools
In this article

If Linux returns Permission denied for a known file, first decompose the path using the namei -l command. It displays the mode, owner, and group for each component. The first directory lacking search permission x for the process is the primary check point; permissions on the final file may be correct.

Do not start with chmod -R, and certainly not with 777. Such a command modifies more objects than required for diagnosis and may obscure the root cause.

What namei -l shows

namei traverses the components of a path, follows symbolic links, and indicates where the resolution stopped. The -l flag enables long format: type, mode bits, owner, and group.

For each intermediate directory, the process requires search permission. If it is missing, the kernel returns EACCES — Permission denied. For a directory, this permission is denoted by the x bit; it differs from the read permission for listing names, which is the r bit. This behavior is described in the Linux path resolution guide.

Output snippet

What is visible

First hypothesis

d--------- locked

The directory lacks r, w, and x

The path will stop for a process without bypass capabilities

app - Permission denied

The next component was not read

Check permissions for a directory named locked

-rw-r--r-- config.ini

The final file is visible

Intermediate directories have already been traversed

Input conditions and boundaries

  • Commands are executed under the same user or process that receives the error.

  • A full absolute path is required, not just the final file name.

  • The test was run in a separate /tmp directory; working files and services were not modified.

  • This check does not replace a separate review of ACL, SELinux, AppArmor, NFS, and container mappings.

Re-test environment on October 13, 2026: Ubuntu 24.04.3 LTS, Linux 6.18.44, util-linux 2.39.3. The current process lacked the capability to bypass standard DAC checks.

Minimal diagnostics

Substitute the actual absolute path of the problematic file:

namei -l /var/www/example/bitrix/.settings.php

Read the output from top to bottom. If the output stops at a directory, the cause lies before the final file. Checking only the final file with ls -l here is unhelpful: the process has not yet reached it.

Example of a characteristic fragment:

drwxr-xr-x root root mikhail-namei-lab-20261012 d--------- root root locked app - Permission denied

The first suspicious component is 'locked'. The line 'app - Permission denied' shows where the process stopped, but changing permissions on 'app' blindly is premature: the 'app' directory is not yet resolved as a path component.

Path components up to the 'locked' directory, where resolution fails due to EACCES
Tutorial path: namei -l stops at 'locked' due to missing search permission.

Reproducible test

In the isolated model, a config.ini file is created inside the locked directory. All parent directories retain standard permissions, after which locked is set to mode 0000.

lab_dir=/tmp/mikhail-namei-lab-20261012 locked_dir="$lab_dir/locked" app_dir="$locked_dir/app" config_file="$app_dir/config.ini" install -d -m 0755 "$lab_dir" "$locked_dir" "$app_dir" printf 'mode=training\n' >"$config_file" chmod 0644 "$config_file" chmod 0000 "$locked_dir"

After this, namei -l reaches locked but cannot resolve app. The read check returns code 1:

namei -l "$config_file" test -r "$config_file" printf 'read_check=%s\n' "$?"

d--------- root root locked app - Permission denied read_check=1

For the test directory, the owner retains rwx permissions, while the group and others are allowed only traversal via x:

chmod 0711 "$locked_dir"

The repeat shows the full path, and the read check returns 0:

drwx--x--x root root locked drwxr-xr-x root root app -rw-r--r-- root root config.ini read_check=0

Locked mode

namei observation

Read check

Output

0000

Stop before app

1

The directory lacks search permission (bit x is off)

0711

The path is displayed in full

0

The component is traversable; the file is readable

Comparison of directory modes 0000 and 0711 in the test
With 0000, the path is unresolved and read_check=1; with 0711, the same process receives the full path and read_check=0.

Both scenarios were executed twice; the final script exited with code 0. The value 0711 was chosen only for the test model and is not a ready recommendation for a production server.

Order on a production server

  1. Record the process user, the full path, and the exact error message.

  2. Run namei -l as the affected user or in an equivalent context.

  3. Find the first component after which "Permission denied" appears.

  4. Verify the expected owner, group, and access mode specifically for that directory.

  5. Check ACLs and security policies if standard mode bits appear correct.

  6. Change only the confirmed object in accordance with an agreed access policy.

  7. Repeat namei -l and the original operation; save both results.

Stop before making changes if it is unknown which user should have access, if this directory is used by multiple services, or if permissions are managed by deployment configuration. Manual edits may then be lost during the next update.

Why root checks can be misleading

Root or a process with CAP_DAC_OVERRIDE or CAP_DAC_READ_SEARCH can bypass some standard access checks. Therefore, a successful namei or cat command run as root does not prove that the path is accessible to PHP-FPM, backup processes, or background jobs.

What namei does not prove

  • namei does not confirm access for another user or a container with different UID, GID, and mount namespace.

  • namei does not confirm that ACLs allow access; ACL restrictions must be checked separately.

  • namei does not show the final SELinux or AppArmor decision; context and profile must be checked separately.

  • namei does not verify the availability of the network file system or the correctness of its user mapping rules.

  • namei does not verify the correctness of the final file's content and owner after a successful path traversal.

How to verify the fix

The result is accepted if namei -l shows the entire path in the correct context, the original operation completes successfully, and the change is limited to a confirmed component. It is premature to rely on a single run as root: repeat the check using the same user who previously received a Permission denied error.

In the training test, the criterion was met: with mode 0000 the path was blocked and read_check was 1; with mode 0711 namei showed the full path and read_check became 0. This confirms the impact of the search permission x on the intermediate directory, but does not apply the selected mode to the production server.

GENERAL IT

Help with your project

GENERAL IT

Read more on this topic

Discussion 0

Share your experience and ask questions. Comments without links appear after editorial review.

No comments yet. Start the discussion.