Courseiva
mediumMultiple ChoiceObjective-mapped

Permission Denied on Service Startup — Diagnose with namei

A user reports that a service fails to start with the error 'Permission denied'. The service runs under a non-root user. Which command should the administrator use to check if the service has the correct file permissions?

Quick Answer

The answer is the `namei -l /path/to/service` command, because a "permission denied" error on service startup under a non-root user often stems not from the binary itself but from missing execute permissions on any parent directory in the path. The `namei -l` command recursively lists the permissions of every component—from root down to the file—so you can instantly spot a directory that lacks the search bit for the service user, which blocks access even if the binary is correctly set. On the CompTIA Linux+ XK0-005 exam, this question tests your understanding that Linux path resolution requires execute permission on each directory, a common trap where students check only the file’s permissions. A useful memory tip: think of `namei` as "name inspector" that walks the entire directory tree, ensuring no "locked gate" blocks the service user’s path.

⚠ Common exam trap

Many candidates assume `ls -l` or `stat` on the service binary alone is sufficient, overlooking that the 'Permission denied' error often originates from a missing execute bit on a parent directory in the path, which only `namei -l` can reveal by checking every component.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

namei -l /path/to/service

The error 'Permission denied' when starting a service under a non-root user often involves not just the file's own permissions but also the permissions of each directory in the path leading to the service binary. The `namei -l` command recursively lists the permissions of every component in the path, revealing if any parent directory lacks execute (search) permission for the service user, which would block access even if the binary itself is correctly set. This makes it the most comprehensive tool for diagnosing path-based permission issues.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • namei -l /path/to/service

    Why this is correct

    namei -l walks the entire path and shows permissions for each component, revealing any 'Permission denied' at intermediate steps.

  • ls -l /path/to/service

    Why it's wrong here

    ls -l shows permissions of the final file, not intermediate directories or symlinks.

  • getfacl /path/to/service

    Why it's wrong here

    getfacl shows ACL entries, but if the issue is basic permissions on a directory in the path, it may not show the problem.

  • stat /path/to/service

    Why it's wrong here

    stat provides details but does not decompose the path; it only shows the final file's inode.

About these practice questions

One of 979 original XK0-006 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

Same concept, more angles

1 more way this is tested on XK0-006

These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.

Variation 1. Given the journalctl output for the httpd service, which of the following is the most likely cause?

hard
  • A.The /var/www directory is missing the execute (x) permission for the Apache user
  • B.The file /var/www/html/index.html has incorrect SELinux context
  • C.The Apache service is running under the wrong user
  • D.The file /var/www/html/index.html is missing read permission for the Apache user

Why A: The journalctl output for the httpd service likely shows 'Permission denied' errors when Apache tries to serve files from /var/www. The most common cause is that the /var/www directory lacks the execute (x) permission for the Apache user (typically 'apache' or 'www-data'). Without execute permission on the directory, Apache cannot traverse into it to access files, even if the files themselves have correct permissions. This is a standard Linux permission issue distinct from SELinux or file-level read permissions.

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This XK0-006 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the XK0-006 exam.