你登录的账号在管理员组里，sudo 用起来毫不费力，于是你自然地以为"这台机器上什么都能改"。直到你要更新 /opt 下某个应用的配置、往 /usr/local/sbin 放个脚本，才发现死活改不动——明明是管理员，为什么这些地方偏偏不行？
现象
- 账号能正常使用
sudo（比如sudo whoami返回 root）； - 但对某些系统目录的改动仍然失败，报
Permission denied； - 典型改不动的位置：
/opt下的应用目录、/usr/local/sbin、/etc下的某些文件。
看起来自相矛盾："能提权"却"改不动"。
根因
根因是混淆了两件不同的事："你有能力提权" 和 "你当前身份对这个位置有写权限"。
需要把两个概念拆开：
- 你是谁。你登录的账号在一个普通用户组里，它对
/opt/app、/usr/local/sbin这类目录根本没有写权限。也就是说，以你当前的普通身份运行cp、echo > file，会被拒绝。 - 你能变成谁。因为你在管理员组、能用
sudo，你有能力临时变成 root（或另一个有权限的身份）去操作。
这两件事不是一回事。直接执行一条写命令时，用的是你当前身份——普通用户，所以被拒；只有显式地在命令前面加 sudo，才会切换到提权身份，才有写权限。
很多人踩坑是因为：脚本里有的命令前面加了 sudo，有的忘了加；或者习惯性地以为"我反正有 sudo，不加也一样"。事实上，有 sudo 只意味着"你可以加"，不意味着"不加也行"。
解决
改动这些位置时，必须显式走 sudo。
# 错误：以当前用户身份执行，被拒
cp app.conf /opt/app/config/
# 正确：显式提权
sudo cp app.conf /opt/app/config/
在无 tty 的远程环境（比如 SSH 里内联执行、CI 脚本里）中，sudo 可能会因为"无法读取密码"而失败。这时可以用从 stdin 喂密码的方式：
echo '<密码>' | sudo -S -p '' cp app.conf /opt/app/config/
-S 表示从标准输入读密码，-p '' 让提示符为空（避免提示信息串进输出）。可以把它封装成一个 shell 函数，用起来更顺手：
# 放到 ~/.bashrc 里
sudop() { echo "$SUDO_PASS" | sudo -S -p '' "$@"; }
# 之后这样用
sudop cp app.conf /opt/app/config/
（密码来自环境变量，注意别把带密码的变量泄漏进日志或历史记录。）
写完记得验证结果，而不是只看命令有没有报错——确认文件确实变了：
sudo ls -l /opt/app/config/app.conf
sudo diff /tmp/app.conf.new /opt/app/config/app.conf
有一点要特别注意：别为了"省掉 sudo"去给普通用户放开系统目录的权限。 有人图省事，直接 chmod 777 /opt/app 或把整个目录的属主改成普通用户，短期是能写了，但代价是把一个本该受保护的系统位置对所有人敞开，埋下安全隐患。正确的方向始终是"在需要的那条命令上提权"，而不是"把权限永久下放"。
另外，如果是通过制表符自动补全或别名（alias）来执行命令，要留意别名里是否带了 sudo。有人给 cp、vi 之类配了别名并顺手加了 sudo，在某台机器上习惯成自然，换一台没配别名的机器就忘了显式加，于是同样的命令时好时坏——这类"环境差异导致的 sudo 缺失"，排查起来也格外费时。
延伸与预防
这条坑的通用教训是：区分"能提权"和"当前身份能改"。
可复用的思路：
- 报
Permission denied时，先问"这条命令有没有加 sudo"。 大量"明明能提权却没权限"的问题，根子就是漏了一个sudo。 - 看脚本里 sudo 的一致性。混合了加和不加 sudo 的脚本，最容易出现"一半成功一半失败"。改动系统路径的操作，统一都走提权。
- 无 tty 环境要用
-S。别指望交互式输密码，远端/CI 环境里准备好从 stdin 喂密码的方式。 - 改完要验证生效，而不是相信"没报错就是对了"。
一句话：权限是"针对某个身份、某个位置"的——换个身份，结论就变了。