Deleting the wrong file almost always turns into an unpleasant surprise. This is especially true on a production Linux server or VPS, where scripts are running, containers are active, CI/CD pipelines are executing, and multiple users have access to the system. In such situations, people usually try to figure out not only how to recover the file, but also who exactly deleted it.
There’s no one-size-fits-all answer to this question, since Linux doesn’t keep a separate deletion log by default. Therefore, after an incident, everything depends on what auditing and monitoring tools were enabled beforehand. But if none were in place, the investigation quickly turns into a search for circumstantial evidence.
In this brief article, let’s try to figure out where it makes sense to look for information and which tools actually help us understand exactly what happened.
Why Linux Doesn’t Keep a File Deletion History
Many people expect to see something similar to the Windows Event Log, with an entry showing which user deleted a specific file and when it happened. Unfortunately, however, most Linux distributions do not have such a mechanism.
In fact, when you use the rm command, the reference to the file system’s inode is deleted. And if file operation auditing wasn’t enabled beforehand, only indirect traces remain after deletion.
Furthermore, the file might not have been deleted by a person, but rather by, for example, a cron job, a systemd timer, a backup process, a Docker container, or an application that cleans up temporary data. Therefore, investigating such incidents usually relies on analyzing several sources of information at once.
Check the Bash command history
If the file was deleted manually via the terminal, the first place to start is the Bash command history. Sometimes this is enough to identify the culprit.
You can do this, for example, by running the following command in the server console:
history
or
cat ~/.bash_history
If multiple users have access to the server, you need to check the history for each account. Also, don’t forget about root, since users often log in under their own account first, then run sudo, and the rm command ends up in the superuser’s history.
However, you shouldn’t rely entirely on the Bash history. History entries are usually only saved after the session ends. Again, a user can disable history saving, delete the .bash_history file, or simply clear the history before logging out. Therefore, this method is more useful as an initial check than as reliable evidence.
Examine System Logs
Even if the fact that a file was deleted isn’t recorded anywhere, system logs often help reconstruct the sequence of events by cross-referencing data from several key logs.
First and foremost, you should check the authentication logs and system event logs:
/var/log/auth.log;/var/log/secure;- the
systemdlog viajournalctl; - logs from services that might have interacted with this file.
The logs usually make it possible to determine who logged into the server shortly before the incident, whether there were any SSH connections, whether sudo was used, and whether cron jobs or other automated processes were running. Very often, simply mapping the events onto a single timeline is enough to rule out most possible scenarios.
But, alas, there’s a catch here as well. The issue is that if file system auditing wasn’t configured in advance, the logs will help you understand the general sequence of events but are unlikely to reveal which specific user deleted a particular file.
Applications and Containers
We all know that a file can be deleted not only by a person but also by applications or automation tools. Among the most common sources of such changes are:
- Docker containers;
- Kubernetes jobs (
Job,CronJob); - GitHub Actions, GitLab Runner, and other CI/CD tools;
- backup and synchronization systems;
- CMS, custom applications, and service scripts.
A typical example would be a scenario where a container running as rootaccesses a mounted volume and deletes files within it. In such a situation, the Bash command history will be of little use. It’s much more helpful in this case to examine the logs from Docker, Kubernetes, or the application itself.
This proves once again that incident investigations shouldn’t be limited to searching for a specific user’s actions, since the cause could be anything.
Can the full picture be reconstructed after deletion?
If file system auditing wasn’t configured in advance, piecing together the full picture of events becomes much more difficult, if not impossible. In such cases, as we mentioned above, you have to look for indirect clues and cross-reference information from various sources.
Typically, in such cases, the following data is examined and cross-referenced:
- the modification time of the parent directory;
- application and service logs;
- the
cronjob history; - system logs;
- backups;
- and monitoring system data.
If the file was in a Git repository, be sure to check the commit history. Since Git keeps track of changes to the project, this often allows you to determine when the file disappeared and who committed that change. However, this only works if the deletion occurred through the normal workflow, rather than directly on the server via the console.
When neither audits, logs, nor other monitoring tools were used, it’s usually impossible to identify the culprit.
How to Set Up the Server in Advance
If your work frequently requires you to know who deleted a file, changed access permissions, or renamed a directory, you should configure the Linux Audit Framework (auditd) in advance. For such tasks, this is one of the most effective built-in tools.
auditdcan log events such as:
- file deletion;
- file creation and modification;
- changes to access permissions and ownership;
- renaming of objects;
- access to specified files and directories.
For example, you can enable auditing for a specific directory:
auditctl -w /var/www -p wa
After that, auditd will begin logging all relevant events. The log will include the time the operation was performed, the user, the process, the PID, and other data that helps reconstruct what happened.
It’s more convenient to create rules with custom keys, as this makes it much easier to find the entries you need:
auditctl -w /var/www -p wa -k webfiles
After that, you can filter events by key:
ausearch -k webfiles
And if you need a general report on the accumulated data, the aureport utility will come in handy.
It is auditd that is typically used on corporate servers, where there are requirements for auditing user actions, investigating incidents, and monitoring system changes.
Conclusion
Unfortunately, it is only possible to reliably determine who deleted a particular file on a Linux server if the system has collected the necessary data in advance. Without auditing, you have to cross-reference command histories, system logs, application logs, and information about automated processes. Sometimes this is sufficient, but often there is too little information to draw conclusions.
For this reason, it’s best to set up monitoring mechanisms before a problem arises. The auditdutility, centralized log collection, regular backups, and system monitoring significantly simplify the investigation of any incidents, while also helping to restore server operation more quickly and understand why the situation occurred in the first place.
