Linux tar 解压时报权限错误怎么办：目录属主、umask 与安全落盘核对

服务器上拿到备份包，执行 tar -xzf release.tar.gz -C /srv/app 却看到 Permission denied，多数时候不是 tar 文件坏了，而是“当前用户能不能在目标路径创建目录和文件”没有核对清楚。先看目标目录的每一级权限，再检查压缩包会写入哪些路径，通常不用给整台机器临时开最高权限。

先分清：是读压缩包失败，还是写目标目录失败

tar -xzf 同时包含读取归档和创建目标文件两个动作。报错出现在解压阶段时，常见的阻断位置有三处：归档文件本身不可读、-C 指向的目录不可进入，或者目标目录可以进入但没有写权限。

第一步：沿着目标路径找到真正的权限拦截点

不要只看最后一级目录。Linux 访问 /srv/app/releases 时，当前用户至少要能遍历 /srv、/srv/app 和 /srv/app/releases；创建文件则还需要对最终目录拥有写权限。

id
namei -l /srv/app/releases
ls -ld /srv /srv/app /srv/app/releases
test -x /srv/app/releases && echo can-enter
test -w /srv/app/releases && echo can-write

如果最后两个检查没有输出，先记录实际执行用户和目录属主。部署脚本经常以 deploy 运行，而手工登录用户可能是另一个账号；在错误用户下反复执行，只会让结果看起来忽好忽坏。

第二步：先列出归档路径，再决定安全落盘位置

解压前用 tar -tzf 只查看清单，不触碰磁盘。重点看归档是以 app/ 开头的相对路径，还是包含绝对路径或上层跳转的异常条目。

tar -tzf release.tar.gz | sed -n '1,30p'
tar -tzf release.tar.gz | awk '/(^\/|\.\.\/)/ {print; bad=1} END {exit bad}'

生产环境更稳妥的做法是先解到当前用户拥有的临时目录，再把经过核对的文件移动到发布目录：

tmp_dir="$(mktemp -d /tmp/app-release.XXXXXX)"
tar -xzf release.tar.gz -C "$tmp_dir"
find "$tmp_dir" -maxdepth 2 -type f -printf '%M %u:%g %p\n' | head
# 确认内容和属主后，再由发布流程写入 /srv/app/releases

这里别急着加高权限。临时目录的价值是把“归档里有什么”和“正式目录能不能写”拆成两个可验证的步骤。

第三步：按运行用户修复属主、组权限和 umask

如果目录确实应该由 deploy 用户管理，可以把发布目录的属主和组改到真实运行账户，而不是简单放开所有人写入：

sudo chown -R deploy:app /srv/app/releases
sudo chmod 2775 /srv/app/releases
sudo -u deploy sh -c 'touch /srv/app/releases/.write-test && rm /srv/app/releases/.write-test'

目录上的 2 是 setgid 位，新建文件会继承目录组，适合部署用户和应用组共同维护的场景。若文件权限总是比预期更紧，再看执行用户的 umask：

umask
umask -S
sudo -u deploy sh -c 'umask; touch /srv/app/releases/umask-test; stat -c "%A %a %U:%G %n" /srv/app/releases/umask-test; rm /srv/app/releases/umask-test'

umask 只会影响新建文件和目录的默认权限，不能修复已有目录的属主，也不能让没有写权限的用户突然获得写权限。

第四步：用最小权限完成一次可重复复测

权限修改后不要直接用管理员账号宣布成功。用和发布任务相同的用户，先创建一个小测试归档，再解压到目标目录；结果同时看退出码、文件属主和目录层级。

sudo -u deploy sh -c '
  set -eu
  rm -rf /tmp/tar-permission-check
  mkdir -p /tmp/tar-permission-check/input
  printf "ok\n" > /tmp/tar-permission-check/input/health.txt
  tar -czf /tmp/tar-permission-check/check.tgz -C /tmp/tar-permission-check/input health.txt
  mkdir -p /srv/app/releases/permission-check
  tar -xzf /tmp/tar-permission-check/check.tgz -C /srv/app/releases/permission-check
  stat -c "%A %a %U:%G %n" /srv/app/releases/permission-check/health.txt
'
echo "tar exit=$?"

如果测试归档能成功落盘，而正式包仍失败，回到归档清单检查是否含有特殊路径、只读文件或需要创建的深层目录。两次测试都失败，再看 ACL 和挂载属性：

getfacl -p /srv/app/releases 2>/dev/null
findmnt -no TARGET,FSTYPE,OPTIONS /srv/app/releases

ACL 可能让传统的属主/组权限表看起来正常，却仍拒绝特定用户；只读挂载则需要先处理挂载来源，不能靠 chmod 绕过。

常见问题

为什么目录显示 rwx，tar 还是提示 Permission denied？

先确认命令实际用户，再检查父级目录的执行权限、ACL 和文件系统是否以只读方式挂载。最后一级目录有写权限，不代表整条路径都可用。

可以直接用 sudo tar -xzf 吗？

临时救援可以，但它可能生成由 root 持有的文件，随后应用用户反而无法更新。若必须使用高权限，解压后要核对属主，并把正式发布纳入可重复的部署用户流程。

umask 设成 022 就能解决解压权限问题吗？

不能。umask 只调整新建对象的默认权限；归档文件不可读、目标目录不可写、ACL 拒绝或只读挂载，都需要分别处理。

收尾检查清单

• 记录执行用户：id。
• 检查路径通行和写权限：namei -l、test -w。
• 检查归档内容：tar -tzf，拒绝绝对路径和上层跳转。
• 优先用属主、组权限和专用暂存目录修复。
• 用真实发布用户复测，并核对最终文件的属主、组和权限。