Activating jail breaks website database connection

OS type and version Debian 10
Virtualmin version 7.1

I set up a website and used the WordPress script to install WordPress 6 (standalone as opposed to multisite). Before I enabled the jail, the Server Configuration > PHP Options showed FPM selected and version 8.0.21 selected.

Once I enabled the jail, if I go to https://domain.tld/index.php I get this rendered for a page (as opposed to the WordPress home page’s site):

<!DOCTYPE html>
<html dir='ltr'>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
	<meta name="viewport" content="width=device-width">
			<title>Database Error</title>
	<style type="text/css">
		html {
			background: #f1f1f1;
		body {
			background: #fff;
			border: 1px solid #ccd0d4;
			color: #444;
			font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen-Sans, Ubuntu, Cantarell, "Helvetica Neue", sans-serif;
			margin: 2em auto;
			padding: 1em 2em;
			max-width: 700px;
			-webkit-box-shadow: 0 1px 1px rgba(0, 0, 0, .04);
			box-shadow: 0 1px 1px rgba(0, 0, 0, .04);
		h1 {
			border-bottom: 1px solid #dadada;
			clear: both;
			color: #666;
			font-size: 24px;
			margin: 30px 0 0 0;
			padding: 0;
			padding-bottom: 7px;
		#error-page {
			margin-top: 50px;
		#error-page p,
		#error-page .wp-die-message {
			font-size: 14px;
			line-height: 1.5;
			margin: 25px 0 20px;
		#error-page code {
			font-family: Consolas, Monaco, monospace;
		ul li {
			margin-bottom: 10px;
			font-size: 14px ;
		a {
			color: #0073aa;
		a:active {
			color: #006799;
		a:focus {
			color: #124964;
				0 0 0 1px #5b9dd9,
				0 0 2px 1px rgba(30, 140, 190, 0.8);
				0 0 0 1px #5b9dd9,
				0 0 2px 1px rgba(30, 140, 190, 0.8);
			outline: none;
		.button {
			background: #f3f5f6;
			border: 1px solid #016087;
			color: #016087;
			display: inline-block;
			text-decoration: none;
			font-size: 13px;
			line-height: 2;
			height: 28px;
			margin: 0;
			padding: 0 10px 1px;
			cursor: pointer;
			-webkit-border-radius: 3px;
			-webkit-appearance: none;
			border-radius: 3px;
			white-space: nowrap;
			-webkit-box-sizing: border-box;
			-moz-box-sizing:    border-box;
			box-sizing:         border-box;

			vertical-align: top;

		.button.button-large {
			line-height: 2.30769231;
			min-height: 32px;
			padding: 0 12px;

		.button:focus {
			background: #f1f1f1;

		.button:focus {
			background: #f3f5f6;
			border-color: #007cba;
			-webkit-box-shadow: 0 0 0 1px #007cba;
			box-shadow: 0 0 0 1px #007cba;
			color: #016087;
			outline: 2px solid transparent;
			outline-offset: 0;

		.button:active {
			background: #f3f5f6;
			border-color: #7e8993;
			-webkit-box-shadow: none;
			box-shadow: none;

<body id="error-page">
	<div class="wp-die-message"><h1>Error establishing a database connection</h1></div></body>

I believe this code being rendered tells me that PHP is working. I have another WordPress site (multisite with about 25 sites in it) running that does not appear to be affected by changes I made to the standalone site.

At this point I again checked Server Configuration > PHP Options which still showed FPM selected and version 8.0.21 selected, just as before the jail enabling process.

I also manually restarted PHP 8.0 to see if that would help (it did not).

Because it is a live site, I undid the jail setting so the site would continue rendering normally (which it did).

Thanks for any guidance,

Just an update pertinent to my original post:

I discovered that turning on the jail in an existing WordPress install somehow appears to disconnect it from its database.

I did the following and it worked:

  • Created a new site with Virtualmin. It’s SSL was set up and it only had the Virtualmin default holder page.
  • Navigated to Administrative Options > Edit Owner Limits >Other restrictions and set the existing website’s jail to yes
  • Checked that the website still resolved at the default page (it did)
  • Navigated to Server Configuration > PHP Options and noted the PHP version set at PHP 8.0.21
  • Navigated to Install Scripts and added WordPress 6.0.1 at top level
  • Was able to log into WordPress and all appeared operational
  • Attempted to change my admin email address but never received the notification sent to my email. That is apparently a different problem!

Everything in this instance appeared to work fine. However, I do not know enough about Virtualmin to be certain the site is actually “jailed” but am trusting it is because the interface shows it in that state.

Unfortunately, I am still left with my original problem of how to jail an existing site on the server.

Thanks for any guidance!


Yes, I’ve seen setting up Jails to do some undesired things. The problem is two fold

  1. I’m not really as knowledgable on the topic as I’d like to offer an immediate work around

  2. I believe all issues relate to the restrictive nature of the system implementing jails. It’s less about it being possible, and more about getting the right configuration down to make it work properly.

On RHEL based systems there is a system called SELinux which again if misconfigured can cause a lot of hardship in terms of getting things to work. This again is because it’s a security system which requires appropriate configuration to get working as desired without creating a security threat.

The solution to the problem with WordPress in jail mode would be changing DB_HOST to, i.e. editing wp-config.php and replacing define( 'DB_HOST', 'localhost' ); with define( 'DB_HOST', '' );

Thanks for figuring that out, Ilia! That definitely solved the issue. I changed the setting from localhost to as indicated. Did it on one standalone WordPress site and one multisite WordPress install with 25+ sites in it.

I am really interested in how you arrived at this solution. Especially since the first line in my /etc/hosts file is: localhost

I did notice that executing a “ping localhost” logged in via PuTTY as root at the command line interface did not resolve an address (as it does at a command prompt in Windows).

Thanks again for any insights - and, of course - for this solution,

a quick google, one solution just check permissions on the hosts file is 644

The hosts file has never changed. In my post above starting out with

Just an update pertinent to my original post:

I mentioned first creating a new site with SSL and then jailing it. Then I ran the script to load WordPress in it. Everything worked. It was using localhost as the database server without issues. I’m fairly confident that the hosts files permissions were not at issue here.

Logically, it appears that when one enables the jail on an existing WordPress install, the connection of “localhost” is lost (as though the word is no longer resolved) and hard-wiring in the configuration file becomes necessary to allow the connection to be made once again. It is as though something is not being restarted/reloaded in the WordPress installation sequence. One thought is that the WordPress install script may have the answer, because when that is used with a jailed site WordPress works (without having to mess with wp-config).

Is this pro version, I don’t see that option, only restriction like that is Chroot jail domain Unix user

No, not pro version. However, we are referring to the same setting - that’s where one chooses Yes or No for the jail (labeled Chroot jail domain Unix user). Newly created sites are initially set to No whenever I create a site.

The issue I ran into is when adding WordPress to a newly created site BEFORE setting the jail to Yes caused the database connection to be lost when changing the jail setting to Yes. So enabling it after WordPress is set up breaks the database connection.

While it’s a relatively easy fix to simply substitute (hardwire) in wp-config, it should not end up broken. I suspect some part of the process that occurs when the jail is set to Yes BEFORE setting up WordPress is skipped when done after.

I just tested on a wordpress site on my server and had no effect on the wordpress site.

Thanks, good suggestion. We have facility for that already. I will fix this for the next release.


Thanks to everyone for the assistance and ideas toward making Virtualmin even better one issue at a time as well as a resolution!

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.