I had a situation where a folder and all its files where being deleted and there were no signs in the VPS error log why this was happening nor what was doing it. As the setup was on a WordPress site I was obviously suspecting either a server rule of some sort or more likely a plugin. Notably I suspected the plugin that needed these specific files and folders.
Reaching out to the author of the plugin I was asked if the plugin was up to date and if I had the pre-requisites in terms of latest WP version and latest version of stable PHP. I tried switching from PHP version 5.3 to 5.4 and it didn't change anything.
The next step was looking at both normal and error logs but this didn't reveal anything.
So I started looking for a way to monitor folders and files, well I started out asking about to see what could tell me what was asking for a file or folder to be deleted and being granted the permission to delete it.
I started looking at ways to monitor what was going on behind the scenes with a server and mostly came across articles to monitor the security of a server which was way beyond what I needed.
I then came across a mention of auditd in this post on linux.com about using Auditd and how it can be set up to monitor in my case a folder being deleted. So I started using this approach to figure out what was going on. I logged in as root via SSH (you may need to use sudo to get to root level). Once in the uploads folder where the folder I needed kept getting deleted, I manually created it:
I then gave it the correct permissions (but not really necessary for this manual test):
chmod -c 755 my_folder_name
I then set up the monitoring as per the above article indicates, where I created a flag/label that is appended to the command and I will then use to search for it in the logs 'monitoring_flag_name' in this case:
auditctl -w /var/www/mydomain.com/htdocs/wp-content/uploads/my_folder_name/ -k monitoring_flag_name
I got the path wrong first and needed to add the /var/ in front for it to work. You can use 'pwd' to get the correct path to the folder you are in.
Then to get the results and get read what auditd has logged you can use the following command, which also confirms that it works, so worth trying out, then running through the steps that allow you to replicate the context that leads to the folder or files getting deleted. This is where you use the flag/label that you set up previously and allows you to quickly sift through any logs created:
usearch -k monitoring_flag_name
I was then able to share these logs, similar to the article above, with the plugin author indicating to confirm that it was being deleted and the sequence of events to help pinpoint what is going on.
Note: I think I read in one of the many articles that a) if you change the rules you'll need to restart auditd and b) if you add rwa parameters they will be lost if you reboot (ie create/set rules that are picked up at reboot)
Hope this helps if you come across the same issues 🙂