Ansible批量部署报“Permission denied”的核心原因是目标主机未向Ansible所用用户开放必要权限，需从执行用户身份、路径遍历权限、模块特定权限及SELinux/挂载限制四方面系统排查。
Ansible 批量部署中报 “Permission denied”，核心不是脚本写错了，而是目标主机上某个环节没给 Ansible 用的用户“开门”。排查要从执行上下文出发：谁在跑？跑在哪？对什么操作？需要什么权限？
确认 Ansible 在目标机上以谁的身份运行
Ansible 默认用 SSH 连接后执行命令，实际身份取决于 inventory 中的配置：
- 检查 play 或 task 是否显式指定了 remote_user（如
remote_user: www-data），这是最权威的依据 - 若未指定，看 inventory 中该主机或组是否设置了 ansible_user 变量
- 都未设置时，默认使用当前控制机登录用户名（比如你本地是
alice，就以alice身份连接） - 用
ansible target -m shell -a 'whoami && id' -v直接验证真实执行用户和所属组
检查目标路径的归属与目录遍历权限
Ansible 报错常发生在 copy、template、file 模块写入目标路径时。重点不是文件本身，而是整个路径链上的每个目录：
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 执行
ansible target -m shell -a 'ls -ld /path/to/dest' -v，看最后一级目录的属主、属组和权限位 - 目录必须有 x（执行）位才能进入——例如
drw-r--r--看似有读写，但缺 x，连cd都进不去，更别说创建文件 - 逐级向上检查：
ls -ld /path /path/to /path/to/dest，确保每一段都允许当前 remote_user 进入（属主匹配且有 x，或属组匹配且有 x，或 others 有 x） - 特别注意：如果 dest 是
/var/www/html/app/logs，而/var/www/html/app属主是root、权限是drwxr-x---，且 remote_user 不在属组里，那连app目录都进不去
验证模块操作所需的最小权限类型
不同模块对权限要求不同，不能只看“能不能读”：
- copy/template：需要对目标目录有 w+x 权限（写入新文件 + 进入目录）
-
file: state=directory：同上，建目录需 w+x；若设
setype或seuser，还需 SELinux 权限支持 - file: state=link：目标链接路径的父目录需 w+x；源文件需 r（读）权限
-
unarchive：解压目录需 w+x；压缩包本身需 r 权限；若用
creates判断，目标判断文件也需 r 权限
排除 Ansible 特有的权限干扰项
有些限制不来自 Linux 基础权限，但会导致同样报错：
-
requiretty 问题：某些系统默认要求 sudo 必须在终端中执行。若 task 用了
become: yes却报 Permission denied，检查目标机/etc/sudoers是否禁用了 requiretty（应有Defaults !requiretty或注释掉对应行） -
sudo 密码策略：若用
become_method: sudo但未配免密，且未传--ask-become-pass，会静默失败。加-vvv可看到提示 “sudo password required” -
SELinux 上下文不匹配：尤其在 CentOS/RHEL 上。执行
ansible target -m shell -a 'ls -Z /path/to/dest'，对比标准 Web 写目录上下文（如httpd_sys_rw_content_t）。不一致时可用file模块的setype参数修正 -
挂载选项限制：若目标路径在 NFS 或 tmpfs 等特殊文件系统上，检查是否挂为
noexec、nosuid或ro——这些会直接拒绝写入或执行
