chmod on Mac: Fix File Permissions From Terminal

Every file on your Mac carries three permissions — read, write, execute — for three audiences: the owner, the group, and everyone else. chmod is the command that changes them, and it's the fix behind two classic errors: a script that says permission denied, and a file someone else can't open.

Read the current permissions first

Always look before you change — the current mode is also your undo. In Terminal:

# human-readable listing
ls -l script.sh

# string form plus the octal number, e.g. "-rw-r--r-- 644"
stat -f "%Sp %Lp" script.sh

ls -l prints something like -rw-r--r--. Ignore the first character (file type) and read the rest in threes: rw- for the owner, r-- for the group, r-- for others. r is read, w write, x execute — for folders, x means "may enter". A trailing @ or + after the mode string means extended attributes or an access control list are present; chmod's mode digits don't touch those. Note the octal number stat gives you; restoring it later is just chmod 644 script.sh.

Numeric modes: 755, 644, and friends

Each digit is a sum: read = 4, write = 2, execute = 1. So 7 is rwx, 6 is rw-, 5 is r-x, 4 is r--. Three digits cover owner, group, others in that order:

# standard document: you edit, everyone else reads
chmod 644 notes.txt

# standard folder or script: you do everything, others read and enter/run
chmod 755 script.sh

# private file: only you can read or write it
chmod 600 secrets.txt

The order never changes — owner, group, others — and on a typical Mac your files' group is staff. Those three modes cover almost everything you'll ever need. Resist 777 — giving every user on the machine write access is never the real fix, and some tools (like ssh, which refuses loose key files) will actively reject it.

For a one-off fix there's also a GUI: select the file in Finder, press ⌘I for Get Info, and edit Sharing & Permissions at the bottom of the panel. chmod earns its keep when you're fixing many files at once, or when Finder's three simple menus can't express the exact combination you need.

Symbolic modes and the +x fix

Symbolic syntax changes one permission without touching the rest — no octal math needed. The one you'll use most: a downloaded script that won't run.

# "permission denied" running ./script.sh? Make it executable
chmod +x script.sh

# undo: remove execute again
chmod -x script.sh

# surgical versions: u=owner, g=group, o=others
chmod u+x script.sh
chmod go-w shared.txt

The letters compose: u, g, o (or a for all), then + to grant or - to revoke, then r, w, or x. If chmod itself answers Operation not permitted, you don't own the file — that's a job for chown, not more chmod.

One thing no mode change can fix: macOS privacy protections. If Terminal is denied access to somewhere like your Desktop or Documents even though the permissions look perfect, that's the privacy system (TCC) talking, not the file mode — grant Terminal access under System Settings → Privacy & Security → Full Disk Access instead of reaching for chmod.

Recursing with -R, carefully

chmod -R applies a mode to a folder and everything inside it. The trap: files and folders want different modes. chmod -R 644 strips execute from the folders themselves, locking you out of navigating them; chmod -R 755 marks every document as an executable. When a whole tree needs fixing, set the two separately:

# folders get 755, files get 644
find ~/Projects/site -type d -exec chmod 755 {} +
find ~/Projects/site -type f -exec chmod 644 {} +

There's no built-in undo for a recursive chmod, so capture the current state first — ls -lR ~/Projects/site > ~/Desktop/perms-before.txt gives you a record to restore from. And skip sudo chmod -R on system paths entirely: macOS protects its own files with SIP, and blanket permission changes under /System or /Library break more than they fix.

When chmod isn't the problem

If permissions look right but you still can't touch the file, check ownership — files copied from another user account or an old drive often belong to someone else entirely. That's chown's job, and the two commands together fix nearly every "permission denied" a Mac can throw.