linux无专门“文件权限冲突记录”，错误为运行时即时抛出；间接线索见/var/log/auth.log或/secure、journalctl -t kernel（含avc日志）、服务自身error_log；诊断应优先ls -l查完整路径权限、id比对用户组、strace跟踪系统调用，并排查acl与selinux。
Linux没有“文件权限冲突记录”这个东西
系统本身不会主动记录“谁因为没权限访问了哪个文件”这类事件。所谓“权限冲突”，其实是访问失败时的即时结果，不是事后可查的日志条目。你看到的 Permission denied 或 Operation not permitted 都是运行时抛出的错误，不会自动存档。
哪些地方可能留下间接线索
虽然没专门的权限冲突日志，但以下位置可能包含相关上下文：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
/var/log/auth.log（Debian/Ubuntu）或/var/log/secure（RHEL/CentOS）：当用户通过sudo、su或 SSH 尝试执行受权限限制的操作时，失败会记在这里，例如：user sudo: pam_authenticate: Authentication failure或sudo: user : user NOT in sudoers -
journalctl -t kernel：内核级拒绝（比如 SELinux 拒绝、capability 不足）有时会输出类似avc: denied { read } for pid=1234 comm="bash" name="config.txt"的 AVC 日志 - 具体服务自己的日志：比如 Nginx 访问静态文件失败时，
error_log里可能出现open() "/var/www/file.txt" failed (13: Permission denied)—— 这里的(13)就是EACCES错误码
真正该做的不是“查记录”，而是复现+诊断
遇到权限问题，优先做三件事：
- 用
ls -l看目标文件和**完整路径上每一级目录**的权限，特别注意目录是否漏了x（否则无法cd或遍历） - 用
id确认当前用户 UID/GID 和所属组，再比对ls -l输出里的 owner/group 是否匹配 - 用
strace -e trace=access,openat,stat跟踪命令实际尝试访问哪些路径及返回码，例如：strace -e trace=access,openat ls /path/to/dir 2>&1 | grep -E "(EACCES|EPERM)"
ACL 和 SELinux 是容易被忽略的隐藏层
即使 ls -l 显示权限没问题，也可能被更细粒度机制拦住：
- 运行
getfacl 文件名查看是否有 ACL 规则覆盖了基础权限 - 运行
ls -Z 文件名（需 SELinux 启用）看安全上下文；若上下文不匹配，setroubleshoot-server可能生成分析建议（但默认常未安装） - 临时用
setenforce 0测试是否 SELinux 导致——仅用于排查，切勿长期关闭
x、用户不在目标组、或 SELinux 上下文错位，而不是等一份“冲突日志”来告诉你。
