Chmod 700 – Linux Permission Guide

What It Means, Explanation, How to Use, When to Use & More

chmod 700

Private Owner-Only Permissions

Apply to a Single File/Folder

chmod 700 [name] Copy

Apply Recursively (Folder + Contents)

chmod -R 700 [directory] Copy

Verify It Worked

ls -l [name] Copy

What Does Chmod 700 Mean?

In Linux, 700 is an octal representation of file system permissions. It grants total control to the Owner while completely locking out the Group and Others.

User (7)

Read + Write + Execute
The owner has full permissions to view, edit, and enter/run.

Group (0)

No Access
Users in the file's assigned group cannot see or touch the content.

Others (0)

No Access
Every other user on the system is denied access entirely.

Why "700"? How the Numbers Work

Every digit in a chmod code is the sum of three values. Once you know the math, you can decode any permission at a glance.

Read (r)

Write (w)

Execute (x)

Add them together to build any permission digit:

7 = 4 + 2 + 1 read + write + execute (full access)

6 = 4 + 2 read + write

5 = 4 + 1 read + execute

4 = 4 read only

0 = 0 no access at all

So 700 reads as: 7 for owner (everything), 0 for group (nothing), 0 for others (nothing).

Permission Matrix (rwx------)

Level	Read (r)	Write (w)	Execute (x)
Owner	✔	✔	✔
Group	✘	✘	✘
Others	✘	✘	✘

Numeric vs Symbolic Notation

chmod accepts two equivalent styles. All four commands below produce identical results:

# Numeric (octal) — the one most tutorials show chmod 700 myfile # Symbolic — set exactly these bits chmod u=rwx,g=,o= myfile # Symbolic — grant to owner, strip from group and others chmod u+rwx,go-rwx myfile # Symbolic — grant to all, then remove from group and others chmod a+rwx,g-rwx,o-rwx myfile

Letters used in symbolic mode: u = user (owner), g = group, o = others, a = all. Operators: + adds a permission, - removes it, = sets it exactly.

How to Verify It Worked

After running chmod, use ls -l to check the result. The first column shows the permissions:

$ chmod 700 secret.sh $ chmod 700 .ssh $ ls -l -rwx------ 1 alice staff 250 Apr 17 14:32 secret.sh drwx------ 2 alice staff 64 Apr 17 14:32 .ssh # First character: "-" = file, "d" = directory # Next 3 chars: owner permissions (rwx = full access) # Next 3 chars: group permissions (--- = none) # Last 3 chars: others permissions (--- = none)

If you prefer the numeric form, stat -c "%a %n" filename prints the permission as an octal number — you should see 700 confirmed.

When to Use chmod 700 (Real Examples)

Securing your SSH directory Most common

SSH refuses to use your key files if other users can read them. This is the #1 reason people run chmod 700. The full recipe:

# The .ssh directory itself — only owner can enter chmod 700 ~/.ssh # Private keys — read/write for owner only, no execute needed chmod 600 ~/.ssh/id_rsa chmod 600 ~/.ssh/id_ed25519 # Public keys and known_hosts — readable is fine chmod 644 ~/.ssh/id_rsa.pub chmod 644 ~/.ssh/authorized_keys chmod 644 ~/.ssh/known_hosts # SSH client config chmod 600 ~/.ssh/config

SSH enforces this via the StrictModes setting in sshd_config, which is on by default. If your permissions are too open, you'll see "Permissions are too open" or "Permission denied (publickey)".

Private scripts you run yourself

A script that contains API keys, internal hostnames, or logic you don't want other users on a shared machine to inspect or run:

chmod 700 deploy-secrets.sh chmod 700 backup-to-s3.sh

Sensitive config directories

Folders holding credentials, tokens, or backups where no other user has any business reading the contents:

chmod 700 ~/.aws chmod 700 ~/.gnupg chmod 700 ~/private-backups

Note: for the files inside these folders, 600 is usually more appropriate since they rarely need to be executable.

chmod 700 vs Other Common Permissions

Before committing to 700, check whether a neighbor might fit better:

Code	Symbolic	Typical Use
`600`	`-rw-------`	Private files that never need to execute — SSH private keys, `.env`, config files
`700`	`-rwx------` `drwx------`	Private scripts you run yourself, private directories you need to `cd` into (`~/.ssh`, `~/.gnupg`)
`750`	`-rwxr-x---`	Scripts or folders you want to share with your group (teammates) but hide from everyone else
`755`	`-rwxr-xr-x`	Default for most directories and executable scripts — everyone can read and traverse, only owner can modify
`644`	`-rw-r--r--`	Default for regular files — owner can edit, everyone else can read (web content, docs)
`777`	`-rwxrwxrwx`	Avoid. Everyone can read, write, and execute. Almost always a security mistake, rarely the real fix for a permissions problem

The `-R` Trap (Read This Before Running Recursively)

Running chmod -R 700 on a folder applies 700 to every file inside, which means every file becomes executable. That's usually not what you want. Regular text files, images, config files, and data files have no business being executable — it's a subtle security smell and can break tools that check permissions (web servers, CI pipelines, SELinux).

⚠ Don't do this on a website directory

chmod -R 700 /var/www/mysite will mark every HTML, CSS, JPG, and PHP file as executable and make the whole tree owner-only — which also blocks the web server user from reading it. Sites go down this way.

The correct recursive pattern sets directories to 700 and files to 600 separately:

# Directories get 700 (owner can enter) find /path/to/target -type d -exec chmod 700 {} \; # Files get 600 (owner can read/write, no execute) find /path/to/target -type f -exec chmod 600 {} \;

This gives you a private tree where directories are traversable and files are readable/writable — without marking every file as executable.

Don't Forget Ownership

chmod 700 only protects the file from the perspective of the owner. If the wrong user owns the file, you've locked everyone else out but given full control to someone who shouldn't have it.

$ ls -l secret.sh -rwx------ 1 root root 250 Apr 17 14:32 secret.sh # Permissions are 700 — but root owns it, not you. # You cannot read or run it; only root can.

Fix it with chown:

# Change owner to "alice" sudo chown alice secret.sh # Change owner and group in one step sudo chown alice:alice secret.sh # Recursively, for a whole directory sudo chown -R alice:alice ~/myproject

Rule of thumb

Always check ownership (the 3rd and 4th columns of ls -l) before setting permissions. Wrong owner + right permissions = still broken.

Troubleshooting

chmod: Operation not permitted You don't own the file.

Only the file's owner (or root) can change its permissions. Either use sudo chmod 700 filename if the change is legitimate, or check ownership with ls -l to confirm whether you should be touching it at all.

chmod: cannot access 'filename': No such file or directory Typo or wrong working directory.

Confirm the file exists with ls and that you're in the right folder with pwd. Remember ~/ expands to your home directory, which isn't always where you ran the command from.

chmod runs but permissions don't change You're on a filesystem that doesn't support Unix permissions.

FAT32, exFAT, and NTFS drives (common on USB sticks, SD cards, and mounted Windows partitions under WSL) ignore chmod. Move the file to an ext4/APFS/Btrfs filesystem, or adjust mount options like umask/fmask/dmask in /etc/fstab.

Permissions are too open — SSH refuses to connect Your ~/.ssh directory or key file is readable by others.

Run chmod 700 ~/.ssh and chmod 600 ~/.ssh/id_rsa. Also check your home directory — if /home/you is group- or world-writable, SSH will also reject keys (chmod 755 ~ or stricter).

I locked myself out of my own folder Recover by resetting to sensible defaults.

For a folder you own: chmod 755 foldername (or chmod 700 if it should stay private). For a file: chmod 644 filename. If root owns it, you'll need sudo.

Reset to Sensible Defaults

If you ran chmod 700 somewhere you shouldn't have (or inherited a broken permission set), these are the safe defaults most systems expect:

Target	Reset Command	Result
Regular file	`chmod 644 filename`	Owner read/write, everyone else read
Directory	`chmod 755 dirname`	Owner full, everyone else read/traverse
Executable script	`chmod 755 script.sh`	Owner full, everyone else read/execute
Entire website tree	`find . -type d -exec chmod 755 {} \;` `find . -type f -exec chmod 644 {} \;`	Directories 755, files 644

Frequently Asked Questions

Why use 700 instead of 600?

Use 700 for directories and scripts — the execute bit (the 1 in 4+2+1) is required to cd into a directory or to run a script. Use 600 for plain files that don't need to execute, like config files, private keys, and .env files. Giving a data file the execute bit isn't harmful, but it's messy and some security tools will flag it.

Is chmod 700 safe?

It's one of the most restrictive standard settings, so yes — it's safer than defaults like 755 in the sense that fewer users have access. It's the required permission for ~/.ssh and is commonly used for private backup and script folders. Just remember: "safe" depends on who owns the file. 700 on a file owned by the wrong account protects the wrong person.

Can the root user still see files with 700?

Yes. The root (superuser) bypasses all standard permission checks. 700 only restricts regular users and groups. If you need protection from root, you need encryption (LUKS, GPG, age), not chmod.

Does chmod -R 700 affect existing files?

Yes. The -R flag stands for Recursive — it applies to the target folder, every sub-folder, and every file inside. This also makes every file executable, which is usually not what you want. See "The -R Trap" section above for the safer find-based approach.

What's the difference between chmod 700 and chmod 0700?

They're identical for everyday use. The leading 0 makes it a 4-digit mode where the first digit controls special bits — setuid (4), setgid (2), and sticky (1). 0700 explicitly says "no special bits, plus 700." You'd write 4700 to set setuid along with 700, but that's rare and you should know why you're doing it before you do.

Do I need sudo to run chmod 700?

Only if you don't own the file. You can chmod your own files freely. For files owned by root or another user, you'll need sudo chmod 700 filename — and you should pause to make sure that's actually the right move.

How do I make newly-created files default to 700?

Set your umask to 077. umask is a "mask" that subtracts from the default creation permissions: with umask 077, new files are created 600 and new directories 700. Add umask 077 to your ~/.bashrc or ~/.zshrc to make it permanent for your user.

Does chmod work the same on macOS and WSL?

On macOS: yes, chmod behaves exactly like Linux on APFS/HFS+ volumes. On WSL: chmod works on the WSL filesystem but is ignored or behaves oddly on mounted Windows drives (/mnt/c/, etc.) because NTFS doesn't natively carry Unix permission bits. Keep files that need real permissions inside the WSL filesystem (~/), not on the Windows side.

–