Fix 'Permission Denied' on Root Directory as Root

The Short Version: What to Do Right Now

You're logged in as root (or using sudo), you ls -la the directory, and you see it's owned by root:root. But when you try to cd into it or touch a file inside, you get "Permission denied". It's frustrating, I know. But the fix is straightforward.

Step 1: Check the directory's permissions

ls -ld /path/to/directory

You'll see something like drwx------. The owner (root) has read+write+execute (rwx). But if the group or others have no permissions, that's fine for root — root should still have access. If you see something like d--------- (no permissions at all), then run:

chmod 755 /path/to/directory

After you run that, try cd /path/to/directory again. If it works, you're done. But if it doesn't, move to Step 2.

Step 2: Check the filesystem mount options

This is the one that catches most people. If the directory is on a separate filesystem (like a mounted drive or a network share), the mount options can override file permissions. Run:

mount | grep /path/to/directory

Look for noexec, nosuid, nodev, or ro (read-only). But the one that kills directory access is noexec — that prevents executing files, not directories. Wait, that's not right. The real culprit is nosuid or nodev? No. The actual one that blocks root from entering a directory is noexec on a directory? No, noexec only affects files with execute bits. The one that blocks cd is nosuid? No. I'm mixing this up. Let me be precise:

A directory needs the execute bit (x) to be traversable. That's a file permission, not a mount option. So mount options alone won't block root from cd'ing into a directory — unless the filesystem is mounted as ro (read-only). If it's read-only, root can't write files but can still cd and read existing files.

So if you're stuck and the permissions look fine, and the mount isn't read-only, then the problem is almost certainly SELinux.

Step 3: The real fix — check SELinux

This is where 90% of these cases land. SELinux can deny root access even when traditional Unix permissions would allow it. Run:

ls -Z /path/to/directory

You'll see the SELinux context, like unconfined_u:object_r:default_t:s0 or system_u:object_r:var_t:s0. If the context doesn't match what the directory expects (like httpd_sys_content_t for a web root, or home_root_t for a home directory), then SELinux will block access.

The quick fix is to restore the default context:

restorecon -Rv /path/to/directory

That command recurses through the directory and sets the correct SELinux labels based on the policy. After it finishes, try accessing the directory again. If it works, great. If not, you may need to set the context manually:

semanage fcontext -a -t httpd_sys_content_t "/path/to/directory(/.*)?"
restorecon -Rv /path/to/directory

(Replace httpd_sys_content_t with the correct type for your use case. For a normal user home dir, use user_home_t. For a system directory, var_t or etc_t.)

Why This Happens: The Short Explanation

Root has DACP (DAC override) in the Linux kernel — it can bypass user/group/other permissions. But SELinux sits above DAC. Even if DAC says "yes", SELinux can say "no" if the security context is wrong. That's the design. It's a feature, not a bug. And it's why you get "Permission denied" as root.

Less Common Variations

Variation 1: The directory is on an NFS or FUSE filesystem

Network filesystems like NFS have their own permission systems. An NFS export can be set to root_squash, which maps root on the client to nobody on the server. Check the NFS export options on the server side. For FUSE filesystems (like sshfs, rclone mount), the FUSE daemon runs as a user, and root on the client might be mapped to that user. Fix: mount with allow_other or uid=0,gid=0 options.

Variation 2: Immutable or append-only flags

Rare but possible. Check with:

lsattr /path/to/directory

If you see i (immutable) or a (append-only), the directory can't be modified or deleted even by root. Remove with:

chattr -i /path/to/directory

Variation 3: AppArmor

On Ubuntu or other AppArmor systems, profiles can restrict root too. Check aa-status and look for profiles that might cover the process or the directory. Tail /var/log/syslog for AppArmor denials.

How to Prevent This from Happening Again

Three things:

Always check SELinux context first when moving or creating directories for non-standard locations. Use ls -Z before you start debugging permissions.
Use restorecon after copying files from one location to another. The context doesn't travel with the file — it's set by the destination policy.
Set mount options explicitly in /etc/fstab for filesystems that need special treatment. Don't rely on defaults.

And if you're dealing with a container or a VM, remember that the host's SELinux policy might block access to bind-mounted directories. In that case, use chcon -Rt svirt_sandbox_file_t /path or set the :Z flag on Docker volumes.