Question: Why does Virtualmin attempt a filesystem-level rm -rf on the global /var/lib/mysql directory when deleting a server that has no_mysql_db=1 and an empty db_mysql= list?
The Issue: I have encountered a critical failure twice where deleting a Virtual Server resulted in the complete deletion of the /var/lib/mysql directory, crashing the database server for all users. After comparing the metadata of a “safe” domain vs. a “disastrous” one, I found a specific inconsistency.
Comparison of Metadata (/etc/webmin/virtual-server/domains/):
Server A (Deleted Safely):
Config:mysql=0, db=lucz_bud, db_mysql= (empty).
Note: The no_mysql_db=1 flag is missing.
Result: Virtualmin ignores MySQL and deletes the server correctly.
Result: Wiped the entire /var/lib/mysql directory.
Hypothesis: My Webmin MySQL module is configured with mysql_data=/var/lib/mysql. It appears that when no_mysql_db=1 is present, the deletion script triggers a cleanup routine. If the db_mysql variable is empty, the resulting command executed as root seems to be: rm -rf /var/lib/mysql/ + $empty_variable ???
This situation occurs when deleting main srv. I’ve noticed a pattern in the configuration where the servers look identical, but only one parameter differs in their configuration. Of course, I can reproduce the error or send you a recording showing step-by-step what we’re doing and the results.
Below is what the configuration of this server looks like
PastedGraphic-1
PastedGraphic-2
PastedGraphic-3
the command except for the slave DNS server deletes correctly (reports an error) because I deleted the zone on the slave DNS earlier.
During the deletion, suddenly all the contents of /var/lib/mysql are deleted
PastedGraphic-4
However, verify that it is not this flag in the configuration that is causing this, because after removing it, the databases are still deleted, it seems to me that the conflict is somewhere else, I don’t know where yet
Attached is the configuration file, and for comparison the test. com file where everything is deleted correctly.
Description: I’ve identified a critical bug in the deletion process. I updated the pam-instalacje server to have MySQL enabled and then attempted to delete it again via the GUI.
The Issue: The entire /var/lib/mysql directory is wiped instantly after clicking “Delete Now,” even before the first log line (“Deleting mail aliases…”) appears.
By the time the script actually reaches the MariaDB deletion step, it fails with: Can't connect to local server through socket '/var/lib/mysql/mysql.sock' (2) This is logical, as the entire directory (including the socket) was already deleted a few seconds earlier.
Key Comparison:
test3.com (Safe): Created and removed immediately using the same account plan as pam-instalacje. It deletes perfectly fine with no issues.
pam-instalacje (Catastrophic): Triggers a total wipe of the MySQL data directory at the very start of the process.
I have identified a critical bug in the virtual server deletion process. When a server has an active bind-mount inside its jail directory, Virtualmin’s cleanup routine recursively deletes the host’s source directory.
In my case, I mount the entire database directory into the jail using “mount --bind /var/lib/mysql /home/chroot/[ID]/var/lib/mysql” to allow socket access.
During deletion, Virtualmin executes a recursive “rm -rf” on the jail’s contents before unmounting them. This command escapes the jail through the bind-mount and wipes the entire /var/lib/mysql directory on the host. This happens in the pre-deletion phase, before any progress logs appear in the UI. I confirmed this by manually unmounting the directory before deletion, which makes the process safe.
Subsequent MariaDB tasks fail with a “Can’t connect to local server through socket” error because the socket and all data have already been destroyed. Virtualmin should be updated to check for mount points via /proc/mounts and unmount them instead of using recursive delete during jail cleanup.
MySQL mounting is due to the fact that if I enable the jailkit for a specific server and then reboot the main server, WordPress, which was installed on that server with the jailkit, reports a DB connection error on localhost, but not on 127.0.0.1. When I disable the jailkit, it works (localhost), and when I enable it again, it works as well.