Your system is not ready for use by Virtualmin?

please I have this error I don’t know what to do this error I don’t know what to do thank you

The first thing you do is give us information about your system and how you got here.

None of our supported OSes would have this problem, at least not in our testing, so I have no guesses how you got this result.

OS type and version Ubuntu Linux 20.04.6
Webmin version 2.105
Usermin version 2.005
Virtualmin version 7.10.0
Theme version 21.09.5
Package updates All installed packages are up to date

THE famous Mr Joe, thank you for your intervention, can you tell me exactly what I should provide you with?


perhaps it is worth checking why /bin/procmail is owned by group mail?

Actually, I’m not sure why this error even exists. procmail can be owned by mail. Not sure why we’d be complaining about it.

But, I should be clear, none of my systems complain about it. So I remain confused how OP got here.

Oh. I think I know what’s going on.

@Alaaeddine.benabid I think you’ve customized the mail delivery command from the usual default of procmail-wrapper to procmail, which is wrong.

Are you on an unsupported architecture (e.g. ARM) and that’s why you changed it?

@Alaaeddine.benabid You need to edit /etc/postfix/ and make sure that mailbox_command is as follows:

mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME

OP obviously changed it from the defaults, I assume that’s because they’re on an unsupported platform and improvised when they saw the error about missing procmail-wrapper. I don’t understand why OP keeps changing things without taking time to understand what they’re changing and why.

I don’t think it should be a “not ready for use” error, though. It should be a warning. If the user understands what they’re doing and won’t be using the VIrtualmin mail stack (which requires procmail-wrapper) then just using procmail is fine. We should probably warn about it in a clearer way, as well, not a vague complaint about ownership which is misleading.

1 Like

It’s pretty much required that either procmail or procmail-wrapper be setuid to root for it to be able to deliver email, so I think this error is correct. Or if you aren’t using Virtualmin’s spam or virus filtering features, the mailbox_command directive can be excluded from

1 Like

But, procmail can’t safely be setuid root. We absolutely should not be encouraging users to open their system up to exploit.

I think the error should explicitly mention procmail-wrapper, and it should just warn about using anything else (anything else means you can’t use the Virtualmin mail delivery stack).

OP broke their system for reasons I can’t discern and I wish they’d stop doing that, but nonetheless, we could provide a more informative error.

1 Like

I think Jamie meant to say procmail-wrapper, as no body should set root setuid on the stock procmail.

I’m sure Jamie said what he meant. He’s just trusting users to understand the implications of things far more than is reasonable for our average user.

procmail in the distant past often did run setuid root. But, many, many, exploits later that stopped being done, AFAIK. I’m unaware of any reasonably safe way to do it without a wrapper that limits inputs.

Then most definitely we should fix the error message, and make it more clear.

Yeah you’re right, only the wrapper can be safely setuid root. So maybe we should change the error message to tell users that mailbox_command should point to the wrapper before complaining about permissions?

So, there’s two things we need to accomplish to make this nice:

  1. Tell users what’s actually wrong (procmail-wrapper is missing, procmail or some other delivery agent is not an acceptable substitute…I’m not sure why, but users often think they can just swap it out).
  2. Allow users to disable the Virtualmin mail processing in an obvious way, so they can get past this problem without doing something crazy. Obviously, they won’t have mail filters, auto-responders, spam/AV, etc. by doing this, and we should probably tell them that, too.

The nicest path is obviously for users to just use the installer on a supported OS and architecture and not go off-roading, especially if they don’t know how things work, but we can make the experience of making mistakes less risky.

Ok I’ve implemented the first one here : Postfix must call procmail-wrapper… · virtualmin/virtualmin-gpl@4b4a0f0 · GitHub

Second will take some more investigation, but I’ll put it on the TODO list.


This is already the case. If Mail for domain feature is disabled in Features and Plugins page, then this check isn’t run.

1 Like

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