Solved: Is this true? Yes it is.

#devops #programming #tutorial #cloud

🚀 Executive Summary

TL;DR: Linux ‘Permission Denied’ errors when cding after su often stem from missing execute (x) permissions on parent directories like /home, not the home directory itself. The problem is solved by granting traversal permissions on the parent directory, either broadly with chmod 711 /home for quick fixes or securely via group ownership with chmod 750 /home.

🎯 Key Takeaways

The execute (x) permission is crucial on all parent directories in a path for successful directory traversal, even if the target directory has full permissions.
chmod 711 /home is a secure and quick solution to enable traversal through /home for all users without allowing them to list its contents.
For production environments, chown root:sysadmins /home followed by chmod 750 /home provides the most secure and granular control, restricting /home traversal to specific administrative groups.

Struggling with ‘Permission Denied’ when trying to cd into a user’s home directory, even after a successful su? You’ve hit a classic Linux permissions trap on a parent directory like /home. Here’s why it happens and the right way to fix it.

Can’t ‘cd’ After ‘su’? You’re Not Crazy, It’s Parent Directory Permissions.

It’s 3 AM. A red alert is blaring from PagerDuty. The prod-api-04 instance is flapping. I SSH in as myself, dvance, and run sudo su – svc\_deploy to check the application logs in its home directory. The switch to the service user works flawlessly. I see the prompt change. Then I type cd ~… and get slapped with bash: cd: /home/svc\_deploy: Permission denied. My heart sinks. The junior engineer on the call is confused, “But… we *are* that user! How can we be denied access to our own home?” I take a deep breath. I’ve seen this movie before, and I know exactly who the villain is.

The “Why”: You Can’t Walk Through a Locked Door

The culprit almost every time isn’t the user’s home directory itself (/home/svc\_deploy). It’s the parent directory, /home. Think of a file path as a series of doors you have to walk through. To get to the svc\_deploy room, you first have to open and walk through the /home hallway.

In Linux, “walking through” a directory requires the execute (x) permission on it. If /home has permissions like 700 (drwx——) and is owned by root:root, then only the root user can open that door. Your svc\_deploy user might own its own directory with perfect 755 permissions, but it can’t get past the locked front door of /home to even reach it. The system correctly denies access before it even checks the permissions on the final destination.

The Fixes: From Quick Triage to Permanent Solution

Okay, enough theory. We’ve got a production server to fix. Here are three ways to solve this, ranging from a quick battlefield fix to the proper, architected solution.

Solution 1: The “Get It Working NOW” Fix (`chmod 711`)

This is my go-to during an outage. It’s safe, fast, and follows the principle of least privilege better than most other quick fixes.

sudo chmod 711 /home

What does 711 (rwx–x–x) do?

Owner (root): Can do everything (rwx).
Group & Others: Can only execute (–x).

This allows any user on the system to *traverse* through /home to get to a subdirectory they have permissions for, but it does not allow them to list the contents of /home. If a user tries to run ls /home, they’ll get a permission denied error. This is great because it prevents users from easily enumerating all other user accounts on the system.

Solution 2: The “Do It Right” Permanent Fix (Groups)

Instead of opening up traversal permissions for *everyone*, a more secure and deliberate approach is to grant them only to a specific group of users who need it, like sysadmins or devops.

Step 1: Create a dedicated admin group (if it doesn’t exist).

sudo groupadd sysadmins

Step 2: Add your administrative user to this group.

sudo usermod -aG sysadmins dvance

Pro Tip: You must log out and log back in for your new group membership to take effect! Run the id command before and after to verify.

Step 3: Change the group ownership of /home and set permissions.

sudo chown root:sysadmins /home
sudo chmod 750 /home

Now, 750 (rwxr-x—) means only root and members of the sysadmins group can traverse /home. All other users are completely locked out. This is the gold standard for production environments.

Solution 3: The ‘Nuclear Option’ (`chmod 755`)

I hesitate to even write this one down, but you’ll see it all over the internet. This is the “make it work no matter what” command.

sudo chmod 755 /home

This works, but it’s lazy. The 755 permission (rwxr-xr-x) gives everyone on the system read (r) and execute (x) permissions. The problem is the read bit. It means any user, no matter how unprivileged, can run ls -l /home and get a complete list of every user with a home directory on that server.

Warning: This exposes all system usernames, which is considered a security information leak. On a multi-tenant server or a system with strict compliance requirements (PCI, HIPAA), this is completely unacceptable. Only use this on your personal dev VM where you are the only user.

Summary Table: Choose Your Weapon

Method	Command	Pros	Cons
The Quick Fix	`chmod 711 /home`	Fast, secure, prevents directory listing.	Affects all non-root users equally.
The Permanent Fix	`chown root:sysadmins /home; chmod 750 /home`	Most secure, granular control, follows least privilege.	Requires user/group management; more setup.
The Nuclear Option	`chmod 755 /home`	Guaranteed to work.	Insecure, allows any user to list all home directories.

At the end of the day, permissions are about intent. What are you trying to allow, and for whom? Understanding that you need the execute bit all the way down the directory path is one of those ‘aha!’ moments for every Linux admin. Choose the fix that matches your security posture, document your change, and get some sleep. You’ve earned it.