CHROOT issues/questions

OS type and version Debian Linux 11
Virtualmin version Version 7.7

I recently had an issue with sending emails from WordPress website forms (see Can't send mail from WordPress forms).

The email transport on the server was working fine as all other emails (from system, etc.) were being sent without issue. What was most bothersome was there were no log files indicating that the hand off of the emails had any issue or were stopped.

The site I tested this with was chrooted, which was apparently the problem. When I turned off the chroot on the site, the issue disappeared.

Can anyone help me understand why this is? In other control panels on boxes I operate, chrooting web spaces for WordPress use has never stopped email from being used from them. Is something set up differently for the chroot process done in Virtualmin?

Also, once I remove the chroot from a site, the chroot directory for that site is not removed by Virtualmin. Shouldn’t it be?

Thanks for any guidance with this!

I don’t think it is the responsibility of Virtualmin to tidy up after you have just decided to do something outside. I would say clear up your own mess. Even more so if you have implemented something at the behest of some other dubious app.

Virtualmin does have an option to chroot a user so therefor i think the op has a valid point however i would only use a chroot on a user that has and will use shell access and also use the correct utilities to add whatever the sys admin deems fit. As Joe pointed out chroot has not much effect to a web user as they have limited access to the system. With regard to cleaning up afterwards there may be files that have been added to the jail that may be required after the jail shell is removed so i guess vm’s idea of leaving the jail intact is valid, to then allow the user to review and copy or delete as required

Sort of understand that - but if the user has added something just because "it was needed by something added external to Virtualmin and not required by virtualmin then it is up to the user to clean up the mess. If I decide to add an application that “requires” the server to run (for example: Go) then I don’t expect Virtualmin to manage it. Just as at the moment it does not do a very good job of managing nginx (it is not very good at cleaning up .conf files) but it does help provide some tools.

In this case the decision to chroot a user seems like one based on external poor advice. not on use of Virtualmin. A decision that led to a long convoluted topic trying to find out what the user had done to break the original basinc install.

Virtualmin offers the ability to chroot in the OP’s instance chroot was added in the thought it would make the server more secure. This is not a case of adding stuff that an app needs to run … to date I have never come across an app that requires a chroot/jailkit. So if Virtualmin offers chroot and the ability to remove it perhaps it should tidy up or ask if the chroot/jailed structure is to be removed or left, so the user can review changes to that environment

Perhaps (as it seems it is not needed for the straightforward use of Virtualmin its use should come with a big red warning message then another on the way out.

So as you say

not needed and best left well alone

I’m not sure what you are meaning here.

The chroot (jail) is installed through the Virtualmin interface.

So it’s not something I

Your statement is akin to saying that if one creates a virtual server under Virtualmin and when it’s no longer needed, then one should have to manually go in and remove it.

Doesn’t that logic bypass the entire reason for control panels and GUIs altogether?

Jim, I’d agree, but my experience is that a customer comes along who needs (or THINKS they need) SSH access and at that point we don’t know where it could go from there. Or a web space becomes hacked after the user’s credentials are acquired and there’s access by a bad player. I’ve been using another control panel since about 2003 on a number of boxes with chroot capability and was advised to use it and have been since back then. I was told then that it is one of various ways to help keep sites secure.

I explained why it didn’t work in that other thread.

You need to add anything you want your chrooted user to be able to use to the jail. To use sendmail, you need to add that command and its libraries to the jail, either using the jk_cp command or adding it to the config file for the jail being created for your users (there are several included jail configs, we default to a quite limited one, for security reasons).

This is true of any use of a jail, regardless of control panel being used to manage things. A chrooted user only sees what you put in their chroot. If you want them to use PHP, you gotta give them php (and maybe the specific extra versions they need, if any). If you want them to send mail, you’ve gotta give them sendmail. As I said, there are some defaults included with Jailkit, or you can make your own and tell Virtualmin to use it.

The point of a chroot is to restrict what the user can and can’t see and do. It’s quite restrictive by default (and by necessity…it’s not all that hard to accidentally give users the ability to escape the chroot).

1 Like

Which sort of explains why it should come with a big red warning. along with busting the myth about added security - yes if you really know what you are playing at and not at the whim of some app.

a domain owner does not really need access via ssh really with there priv level they can do nothing to the system barr look at directories they have privs to … This is the point of webmin/virtualmin it negates the need for ssh access as webmin/virtualmin has

  1. a File manager that can cover most file operations (upload/download/new/delete + more)
  2. a terminal that gives the same access as ssh
  3. a lot of things a domain owner would need wrapped up in the virtualmin gui

so what do you think the user would benefit from having raw ssh access ?
As the virtualmin terminal is that good, to the point I have not broken it yet, On my own server I am thinking of removing native ssh access and using just the virtualmin terminal if the user ever wants to use it. I have found most domain owners seem to use the file manager and the virtualmin menuing system to edit what they need and very seldom use the terminal.
It may be true other panels may ‘nurse maid’ a jail by adding virtually everything to the jailed user but perhaps that is not required and the sys admin (i.e you) should have a total say what system files are added to the jail to avoid possible break outs of the jail.
maybe this is just a way of an new way of sys admin to you but it does work, but I guess each to their own

CHROOT is a means of locking down users. I guess whoever, distro?, decided that sendmail might be a problem for users you want to lock down?

I think various jails are used for FTP users that you want to give the ability to make website changes and pretty much nothing else.

No. The distro had nothing to do with defining the jail configurations (though I guess they could, jails are not a thing most people care about). The upstream jailkit source provides them (and as far as I know, they’re mostly unchanged by the distros that do package jailkit, and our package for RPM-based distros does not alter the jails…we used to fix a bug in one of the jails from upstream, but it’s now been fixed upstream, and we no longer customize it).

There isn’t any judgment happening at the distros. They don’t care. It’s just another package to them, and it’s a very rarely used package in most contexts; you won’t find any Debian/Ubuntu/RHEL core documentation about Jailkit, because jails are not very useful, it’s just a thing people in the hosting world like.

But, the idea is that you’ll configure the jail to suit your needs or the needs of your users, and with the commands you’re comfortable with them having. There are a handful of predefined jail configurations, and you can create as many of your own as you want. I guess we should spend more time on either documenting that or making the default jail do the usual things people expect to be able to do when they ssh in (but that negates most of the already small security benefit of a chroot jail).


This is getting me closer to what I have been trying to figure out, Joe.

Sorry about not knowing exactly what questions to ask and thanks for your patience as I grope through this topic. What I am understanding better now is that chroot is set up differently amongst different systems. In my naivety I thought of it as a single function that worked the same across different platforms.

I would like to be able to use mail from sites using chroot in Virtualmin. So it appears I need to research a little more about exactly how I go about doing that in the Virtualmin environment. That was what I was hoping to learn using this forum thread.

What I’ve learned so far is that chrooting is like believing in different religions - everyone thinks theirs is the right one. Beliefs aside, I’m gathering that chroot can be considered a security measure, but that it’s a basic and limited one. It looks like it can help to isolate processes and limit the potential impact of a security breach. However, it is not foolproof and can be circumvented under certain conditions, especially if the process running inside the chroot jail is running with root privileges. I’ve read that chroot is best used as one layer in a multi-layered security approach. It can add an extra hurdle for an attacker to overcome, but it should not be the only protection mechanism in place.

Sounds like I need to know more about

Joe, you said

so I’m curious how I would find out more about that to be able to add to it.

We use Jailkit for Jail creation and management (probably most others do, too, except maybe cPanel who have a lot of their own in-house tools and custom build everything), so the Jailkit site is a good place to start: Jailkit - chroot jail utilities

Last I checked Debian (and Ubuntu) did not build Jailkit with capabilities, and so they are more likely to be dangerous than on RPM-based distros, where we provide the package and it has capabilities enabled. The chroot is created with full root privileges on those distros, and if exploited at that stage, it would potentially provide root access to the system, not merely a chroot escape (having it build to use capabilities means it only has the ability to create a chroot and maybe one other privilege I can’t recall, so it’s less of a threat, though still potentially problematic). So…I kinda think using chroot jails on those distros is negative for security. The likelihood of an exploit is probably pretty small, if you are careful about what you put in your jail(s) and what permissions they have. It’s an old codebase, and has had lots of time to become well-understood. I recommend reading and understanding this specific page, in particular, Jailkit - chroot jail utilities before using jails.

Thanks for taking the time to explain this, Joe.

Since we started moving into WordPress (kicking and screaming I might add) about 15-20 years ago it’s now 98% of the sites we build and host so it’s important website forms work.

My experience since 2003 has been with DirectAdmin and recently going all Debian on those boxes as well as a couple of recent Virtualmin boxes. In DirectAdmin’s “Jail” (my ONLY experience using “Jail” functionality) WordPress sites do not encounter any issue with sending mail through their forms.

Thanks to your input, Joe, I’ve been reading the suggested info on and really understand now that I had little idea overall of Jailkit!

Of course, I have no idea for sure what “flavor” of Jailkit DirectAdmin is using. But even looking through Oliver’s material I don’t see where it’s directly explained how to get mail OUT of the Jail. Unless the part where he explains how to let it IN does both. I find that piece confusing.

If anyone can help me understand better how to allow sending mail from the Virtualmin “Jail” that would be a great help.


To send mail using the sendmail command, you need to add the sendmail command to the jail, either via jk_cp (for one user jail) or by adding it to the jail configuration file (which will add it to future created jails).

Ok, bear with me while I try to wrap my brain around this - does this mean sending the user out of the jail to use sendmail or copying all of sendmail in its directory structure into the jail?

Is it possible that without the sendmail being set up correctly, the condition could occur that there’d be no error or anything else obvious from within the jail when one tried sending mail from in the jail?

It means neither.

It means literally using the jk_cp command to copy one command (sendmail) into the jail. The jk_cp command copies all library dependencies into the jail, as well.

I don’t know what this means. But, there was an error when you tried to send mail from within the jail; it was a command not found error, and it was because sendmail was not in the jail.