chmod Cheatsheet - Linux File Permission Reference
A permission failure usually announces itself as one line - Permission denied - while the real cause might be a wrong bit order, a directory missing execute, a mismatched group, or an umask silently rewriting the defaults of every new file. Once owner, group and others are understood as a triple of permission sets, plus the SUID, SGID and sticky special bits, the nine characters printed by ls -l stop being runes and become an expression you can do arithmetic on. This sheet shows numeric and symbolic modes side by side for the same permissions, states which position each one lands on, and gives the special bits their own section because they do not change who may read or write - they change how permission is granted. SUID makes a program run as the file owner, SGID makes new files in a directory inherit its group, and sticky restricts deletion to the owner. Reach for it when chmod +x still fails, a log directory refuses writes, SSH rejects a private key, or a container reports owner 1001. It is less expressive than ACLs, but it is the most portable form and the only one Docker COPY and deploy scripts honour.
Typical Use Case
For developers and operators managing Linux file permissions. The core is three things: numeric mode where r=4, w=2 and x=1 add up, symbolic mode using u/g/o/a to add and remove, and the fact that x on a directory means something entirely different from x on a file — on a directory it means you may enter it, and without it cd fails even when r is set. This sheet covers numeric and symbolic modes, the special permissions (SUID, SGID, Sticky), common combinations and umask, with the two extremes worth avoiding called out: 777 and 600.
Permission Bits 6
r (read)w (write)x (execute)- (no permission)u g oaNumeric Mode 6
chmod 755 filechmod 644 filechmod 700 filechmod 600 filechmod 777 filechmod 750 dirSymbolic Mode 6
chmod u+x filechmod go-w filechmod a+r filechmod u=rw,go=r filechmod +x script.shchmod -R 755 dir/Special Permissions 6
chmod u+s file (4755)chmod g+s dir (2755)chmod +t dir (1777)chmod 4755 filechmod 2755 dirchmod 1777 dirCommon Patterns 6
644755600640700750Related Commands 7
chmod --reference=file1 file2chown user filechown user:group filechown -R user:group dir/chgrp group fileumask 022umask -SParameter matrix
| Parameter | Effect | Example |
|---|---|---|
r / w / x | 读 4 / 写 2 / 执行 1 | rwx = 4+2+1 = 7 |
u / g / o / a | 所有者 / 组 / 其他人 / 全部 | a 等价于 ugo |
755 | 可执行文件与目录的标准权限 | chmod 755 script.sh |
644 | 普通文件：所有者读写，他人只读 | chmod 644 config.yaml |
600 | 仅所有者读写，私钥标准权限 | chmod 600 ~/.ssh/id_rsa |
640 | 配置文件：所有者读写，组只读 | chmod 640 /etc/shadow |
700 / 750 | 私有目录 / 共享目录 | chmod 750 /opt/app |
u+x / go-w / a+r | 符号模式加减单个权限 | chmod u+x entrypoint.sh |
u=rw,go=r | 符号模式直接设置（等于覆盖） | chmod u=rw,go=r file |
chmod -R | 递归修改目录下所有内容 | chmod -R 755 dist/ |
u+s (4755) | SUID：执行时以所有者身份运行 | chmod 4755 /usr/bin/ping |
g+s (2755) | SGID：目录内新建文件继承组 | chmod 2755 /shared |
+t (1777) | Sticky：他人只能删自己的文件 | chmod 1777 /tmp |
--reference | 参照另一个文件的权限设置 | chmod --reference=file1 file2 |
umask | 新建文件的默认权限掩码 | umask 022 |
Common pitfalls
Symptom目录已经 chmod 755 了，但 cd 进去报 Permission denied。
Cause缺少 x 权限时无法进入目录，即使同时有 r 权限（r 只影响能否列出目录内容）。
Fix补上执行位：chmod u+x dir（目录通常需要 755）。
Symptomchmod 777 之后服务反而起不来了。
Cause全权限会让安全模块（如 SELinux、AppArmor）与部分程序拒绝执行；也扩大了被篡改风险。
Fix按最小权限原则改回 755 或 640；程序无法执行时先查 SELinux 日志而不是加权限。
SymptomSSH 提示 UNPROTECTED PRIVATE KEY FILE 而拒绝登录。
Cause私钥权限过宽（group 或 other 有任何权限都会被拒绝）。
Fixchmod 600 ~/.ssh/id_rsa，同时目录需要 700。
Symptomchmod -R 之后整个目录树权限被改乱，难以恢复。
Cause递归把本该不同的权限统一了（如把 600 的私钥也改成 644）。
Fix递归前先备份；改用 --reference 或按目录逐层设置，避免无差别 -R。
Symptom给脚本加了 +x 之后 ./script.sh 仍报 Permission denied。
Cause缺少解释器声明（shebang），内核不知道该用什么执行。
Fix在脚本首行加 #!/bin/bash 并确认解释器路径存在。
Symptomchown 改了所有者但程序还是访问不了。
Cause权限同时受属主、属组与其他人三类约束，改属主未必放开组或其他人的限制。
Fixchown user:group file 后确认权限位：ls -l 看 rwx 组合，必要时补 chmod。
Symptom新建的脚本默认没有执行权限，批量部署时全都要加。
Causeumask 只影响新建文件的读写位（通常是 644），执行位需显式设置。
Fix部署脚本里显式 chmod +x，或用 install -m 755 指定权限一步到位。
Troubleshooting
1查看当前权限并逐位解读
ls -l file十位字符：第一位是文件类型，后九位依次是 u/g/o 的 rwx。
2修复私钥权限
chmod 600 ~/.ssh/id_rsa && chmod 700 ~/.ssh私钥必须 600、目录必须 700，否则 ssh 会直接拒绝使用。
3参照已有文件的权限设置
chmod --reference=template.conf new.conf比手写数字更安全，避免把本该私有的文件改成公开。
4确认默认权限掩码
umask -S符号形式显示更直观；umask 022 对应新建文件 644、目录 755。
5批量设置目录树权限
chmod -R 755 dist/仅对确定统一权限的产物目录使用，私有文件目录切勿 -R 755。
Command Examples
Make a script executable and run it
chmod +x deploy.sh
./deploy.shchmod +x 等价于给三类用户都加执行位。省略 ugo 时默认是 a。注意 Windows 编辑过的脚本带 CRLF 会报 bad interpreter，用 dos2unix 转一下。
Lock down private key permissions
chmod 600 ~/.ssh/id_ed25519SSH 拒绝使用组或其他用户可读可写的私钥，报 UNPROTECTED PRIVATE KEY FILE。600 是私钥唯一正确的取值。
Copy permissions from a reference file
chmod --reference=deploy-prod.sh deploy-staging.sh
stat -c "%a %n" deploy-*.sh--reference 避免凭记忆重敲数字，尤其在多台机器上批量对齐权限时。改完用 stat 确认实际生效值。
Output
755 deploy-prod.sh 755 deploy-staging.sh
Common Pitfalls
- chmod 777 lets any user modify the file, so once anything on the host is compromised that path has no protection — avoid it.
- Private keys must be 600; SSH refuses to use a key readable by group or others.
- A 0 in numeric mode clears those permissions, so chmod 000 makes a file inaccessible; recovery requires root.
- A CRLF script edited on Windows fails with bad interpreter after chmod +x — that is a line-ending problem, not a permission one.
- Changing permissions is not the same as changing ownership; combine with chown when access, not just mode, is the issue.
Tips
- Numeric mode: r=4, w=2, x=1; sum them for the value (e.g. rwx = 4+2+1 = 7).
- A directory's x means you can enter it (cd); without x, even r won't let you in.
- SUID has no effect on scripts (only on binaries) and is a security risk — use with caution.
FAQ
What do 755, 644 and 600 mean?
Numeric mode splits permissions into r=4, w=2, x=1 across owner, group and others. 755 = rwxr-xr-x gives the owner full access and read/execute to everyone else — typical for executables and directories. 644 = rw-r--r-- leaves only the owner able to write, good for ordinary files. 600 = rw------- is owner-only read/write, the right choice for private keys such as your SSH key.
Why does my script still not run after chmod +x?
Two usual causes. First, line endings: a script edited on Windows has CRLF, which produces a bad interpreter error — convert with dos2unix or sed -i 's/ $//' script.sh. Second, the shebang path may not exist: check that the #! line matches a real interpreter on the machine. Apply chmod +x and then run it.
When do I need SUID, SGID or the sticky bit?
SUID (u+s, e.g. chmod 4755) runs a program with the file owner's identity — passwd editing /etc/shadow is the classic example. SGID (g+s, e.g. chmod 2755 on a directory) makes new files inherit the directory's group, which suits shared team directories. The sticky bit (+t, as on /tmp at 1777) lets only a file's owner delete it, preventing accidental cross-deletion.
What is the difference between chmod and chown?
chmod changes permission bits — who can read, write or execute. chown changes the owner and group. To let a colleague read a file, chmod 644 or chmod g+r is enough; you only need chown user file when handing management to someone else. In practice prefer permissions, since changing ownership usually has a wider blast radius.
Is chmod 777 ever acceptable as a shortcut?
No. 777 lets any user modify the file, so any compromised process can replace it — you have effectively given up control of that path. Use 755 for executables, 644 for read-only files and 600 for anything sensitive like private keys. If permissions still look wrong, check whether SELinux or the umask is the real cause before loosening bits further.
Official References
Each command links to its official documentation below, so you can verify the latest usage and read deeper.
Maintained by LaoHand
Publicly updated on Jul 21, 2026, continuously proofread against official docs.
Contact Us
Wrong command or description? Send us corrections, business inquiries or product feedback by email.
Contact Us