Linux如何查服务器接收哪些文件，文件传输记录怎么查？

查Linux服务器接收了哪些文件，核心思路是在文件系统事件和系统日志两个层面同时下手，inotify监控加auditd审计是目前最可靠的组合方案。

我在日常运维里被问到最多的问题就是“服务器到底收了哪些文件”，这看起来是个小事，但真要靠翻目录一个个找，效率太低了，文件接收场景五花八门FTP上传、HTTP上传接口、SFTP传输、共享目录落盘，每一种都留下了不同形态的痕迹，这篇内容把排查思路拆开，从实时监控到事后悔日志,给你一套不用装商业软件也能落地的操作方案。

加载中

如何把文件上传到Linux服务器

请叫我Perry

482264-

原视频地址

用inotify实时监控，定位linux服务器接收哪些文件

要第一时间知道文件落地，inotify机制是Linux内核自带的能力，它能把文件创建、写入、关闭这类动作推送给用户态程序，不需要轮询扫描目录，效率很高,市面上大多数文件监控工具都基于它。

安装与基础使用方式

在Debian系或者CentOS系服务器上，装一个inotify-tools工具包就够了，这个包提供了两个命令：inotifywait负责等待事件，inotifywatch负责统计事件。

# CentOS/RHEL系列
yum install inotify-tools
# Debian/Ubuntu系列
apt install inotify-tools

想盯住/data/uploads这个目录,执行以下命令：

inotifywait -m /data/uploads -e create -e moved_to --format '%w%f 时间:%T' --timefmt '%F %T'

-m表示持续监听，-e create -e moved_to分别匹配新文件创建和文件移入目录的动作，格式参数把文件完整路径和到达时间打到屏幕上一行一条，清晰可读，执行之后别关终端，往目录里丢个测试文件,事件会立刻被打印出来。

落盘监控延伸：区分“写了一半”和“写完”

单纯靠create事件判断文件完整到达不太靠谱，FTP客户端传大文件时，通常先创建一个临时文件，写完再重命名，因此推荐组合监听close_write事件,它才是文件写入完成的重要信号。

inotifywait -m /data/uploads -e close_write -e moved_to --format '%f 完整到达'

体验一下区别：文件长时间保持“正在写入”状态，不会触发close_write，只有写操作结束后事件才出现，需要监控上传完整性的场景，这个参数组合比单独的create可靠很多。

配合Shell脚本自动记录文件信息

光在终端打印不是运维的常态，落到日志才能追踪历史，把命令放进一个脚本里,每捕捉到一个事件就追加一行到日志文件。

#!/bin/bash
inotifywait -m /data/receive -e close_write --format '%w%f|%T' --timefmt '%Y-%m-%d %H:%M:%S' | while read line
do
    echo "$(date '+%s')|$line|$(stat -c%s "${line%%|}")" >> /var/log/file-receive.log
done

这个脚本不仅记录时间、路径，还用stat取到了文件大小，曾经用这个模式排查过一起半夜文件丢失的事故，日志显示文件确实到达了本地磁盘，但后续处理进程崩溃没接住，这就把问题定位从“传没传”推进到了“处理没处理”,排查效率直接翻倍。

行业共识认为，inotify是轻量级监控的首选，但在高并发目录下，大量事件堆积可能导致信息丢失，碰到严格审计要求的场景,得启用更底层的方案。

从日志挖线索：linux查看上传文件记录的三种路径

别只盯着文件系统，Linux自带的各种审计日志其实早就把文件活动记下来了，只是很多人忽略了它们,这里列出三条典型的查询路径。

auditd审计日志还原接收过程

auditd是Linux标准审计服务，它能记录“哪个用户、在哪台机器、做了什么操作”,这些信息是普通文件时间戳给不出来的。

开启方式：

systemctl start auditd
systemctl enable auditd

添加规则，监控/data/web/upload目录的写操作和文件创建：

auditctl -w /data/web/upload -p wa -k receive_files

-w指定监控路径，-p wa表示监控写入和属性变更，-k是自定义标识名，之后所有相关操作会被写进/var/log/audit/audit.log,查询这个标识的记录：

ausearch -k receive_files -ts recent

里关键是uid、auid、comm这几个字段。auid是登录原始用户ID，comm是触发操作的程序名。如果看到comm是sftp-server，说明这是通过SFTP传上来的；如果是nginx，多半是走HTTP接口上传的。

rsyslog过滤接收事件

多数服务器的rsyslog配置里，各种服务的日志都在这里汇合，FTP服务（如vsftpd）默认会记录传输完成的日志，Nginx的access_log会记录HTTP上传请求的响应码。

有用的查法是把上传请求单独摘出来，Nginx日志通常包含request_method和request_uri，用grep过滤POST请求并筛选特定路径：

grep "POST /upload" /var/log/nginx/access.log | awk '{print $1, $7, $9}' | tail -20

awk按空格切分后，$1是客户端IP，$7是请求路径，$9是状态码。状态码201或204通常代表文件接收成功

,配合POST路径就能还原出接收文件的时间点。

shell history和命令行痕迹

某些文件接收方式不是在服务端留下日志的，而是运维人员手动通过scp或rz命令拉进去的，这种场景查~/.bash_history反而是最快的：

history | grep -E 'scp|rz|wget|curl'

看到类似scp user@192.168.1.10:/data/file.tar.gz .这样的记录，文件来源和目标一目了然，这条路径虽然“土”,但在小规模服务器上非常实用。

静态盘查：排查linux服务器接收文件的现状

服务器已经运行了一段时间，没有提前部署监控，那要怎么查已经接收的文件？有几个基础命令组合能快速勾勒出近期文件到达的全貌。

find命令按时间和类型定位

用find按修改时间找出最近一天内新出现的文件：

find /data -type f -mtime -1 -exec ls -lh {} ;

-mtime -1表示24小时内修改过的文件，-type f限定为普通文件，加上-exec ls -lh输出文件大小和修改时间，一眼就能看出哪些是上传进来的，想要更精确到小时范围，可以说-mmin参数，如-mmin -120就是过去120分钟内变更的文件。

lsof命令看文件被谁打开

lsof常用来排查“文件是不是正在被某个进程使用”，也能辅助判断接收文件的状态。如果一个文件被FTP服务进程持续持有写句柄，说明它还在传输中。

lsof +D /data/receive

这条命令列出/data/receive目录下当前被打开的所有文件及相关进程PID，输出中FD列是w表示写模式打开，COMMAND列是进程名，看到vsftpd的进程拿着写句柄，就知道当前还有文件正在传输,还没接收完。

du和stat综合看目录增量

最粗犷但有效的方式是看目录体积变化：

du -sh /data/receive

隔几分钟跑一次，对比数值就能判断是否有新文件落盘，大文件场景下，体积跳变非常明显，精确到单个文件，用stat看时间戳：

stat /data/receive/2026-04-01.tar.gz

输出中Birth time字段在部分文件系统上标记了文件创建时间，Modify time最后修改时间，两个时间一对比，就能判断文件是一口气传完的,还是挂了很久才传完的。

多场景落地：综合方案设计参考

不同服务形态的文件接收，侧重点差异不小,这里针对典型场景给出监控要点表：

由上表可见，FTP/SFTP场景下auditd提供的信息更完整，因为系统层面的审计能记录发起传输的用户身份；HTTP上传场景主要依赖Web服务日志，因为应用层协议的状态码本身就是接收结果的直接反馈，事前部署时，混合使用inotify实时监控和auditd审计追踪,基本能覆盖所有文件接收入口。

常见问题解答

如何查看服务器接收文件的时间点？

用stat命令查看文件时间戳：stat /path/to/file，输出中“修改时间”（Modify）即为文件内容最后写入完成的时间，结合ls -l --time-style=full-iso获取秒级精度，判断精确接收时刻完全没有问题，如果文件有多个副本，还需要用find的-newer参数做时间点比较,判断哪个事件先发生。

linux查看服务器接收哪些文件时不装软件行不行？

不装软件可以，auditd和rsyslog通常是系统自带组件，直接启用即可；查看历史文件用find、stat、lsof都是系统基础命令，不装新软件的前提是你能接受一定的功能妥协，比如inotify的实时推送能力用不了,只能通过日志和定时巡检补位。

监控目录时候误报了怎么办？

误报通常来自程序自身的临时文件写入，解决方法是过滤进程名或者文件后缀，inotify脚本里可以通过在读取事件时校验后缀来排除，如[[ "$line" == .tmp ]] && continue，auditd的规则层面则可以用-F dir=/data -F exclude细化排除条件,让规则只覆盖真正需要关心的文件类型。

文件接收排查没有一劳永逸的万能解，但掌握了inotify、auditd、日志分析这三个层面，日常大多数排查场景都能应对。先实时监控抓现场，再日志审计溯源头，配合静态命令查历史，线上文件接收情况就能基本掌握。 这套方法论不需要重金购入商业软件,系统自带工具就足够撑起一套清晰的排查体系。